- If cache and free memory are counted together, I have about half of my memory "free", yet Cacko's memory applet often nudges into the yellow, and when I check, I see "free" is very low, about a meg, but there is always plenty of "cache". Right now I have 5MB "free" and 25MB "cache".
- I'd like to tell the system to be more aggressive about reducing the "cache" part, so I'll have more "free" part. I'd be much happier to see cache limited to about 10MB, just to see how the system responds with that, and have the rest be left as free RAM. I'm not entirely convinced that it's freeing cache when it's low on memory, and I have a hard time believing it really needs 20MB of cache at all times.
- I'm thinking of trying this same thing on this FC4 desktop system. It's got a paltry 256MB RAM, and uses RDRAM, so upgrading isn't really an option. It shows a paltry 48MB free, and I don't like that, when top shows 122MB cached. Seems to be a Linux trait. (grin)
- Is cache size reduction possible? If so, how does one go about it? Thanks for your time...
Full Version: How Does One Reduce The System Cache Size?
OESF Forums > Distros, Development, and Model Specific Forums > Distro Support and Discussion > Sharp ROMs
Well, I read your comment and I was all set to come back and say "It's doing what it's supposed to be doing and you can't change it anyways, so don't worry about it," but then I did some reading.
For the Zaurus I can say with relative certainty that it really is freeing cache just fine exactly when it needs to. Linux is much more agressive about disk caching than other operating systems and it can make people used to other operating systems nervous to see so little memory marked as free. So, you really don't need to worry about it. The 2.6 kernel has some nice options for tuning the VM system through /proc/sys/vm/ , but 2.4 doesn't seem to have that kind of stuff exposed. If you're really concerned about it you might be able to do some basic tuning by looking at information on this page.
On your FC4 machine it's an entirely different case for two reasons:
1) The 2.6 kernel has all sorts of neat VM tuning parameters
2) The presence of swap
If you want less cache because you want to reduce how often it swaps out you can tune the "swappiness" value by doing:
Instead of 60 put different values between 0 and 100. At 0 the kernel will avoid swapping until it's really necessary. At 100 it will swap whenever it seems like a good idea to do so. Experiment however much you want since your settings will get put back to default (probably 60) when you reboot. The swappiness value is really a personal choice on a desktop. Basically it's a tradeoff between having a nice big disk cache (start open office, close it, open it again and it shows up instantly since it was still in cache) and not having to hit swap too often. If you really just want to see a bigger number next to "free memory" there's another setting to change called min_free_kbytes. It sets how much memory the kernel will keep for itself. This is almost certainly not something you want to change unless you're having problems with things living in kernel space not being able to allocate memory. Like all settings in /proc however it goes away on reboot, so go crazy.
Anyways, my take on all this is that any memory that's called "free" might as well be called "wasted." Linux takes the same view on this and thus tries to do something useful (cache) with any memory that would otherwise just sit there unused.
-John
For the Zaurus I can say with relative certainty that it really is freeing cache just fine exactly when it needs to. Linux is much more agressive about disk caching than other operating systems and it can make people used to other operating systems nervous to see so little memory marked as free. So, you really don't need to worry about it. The 2.6 kernel has some nice options for tuning the VM system through /proc/sys/vm/ , but 2.4 doesn't seem to have that kind of stuff exposed. If you're really concerned about it you might be able to do some basic tuning by looking at information on this page.
On your FC4 machine it's an entirely different case for two reasons:
1) The 2.6 kernel has all sorts of neat VM tuning parameters
2) The presence of swap
If you want less cache because you want to reduce how often it swaps out you can tune the "swappiness" value by doing:
CODE
echo 60 > /proc/sys/vm/swappiness
Instead of 60 put different values between 0 and 100. At 0 the kernel will avoid swapping until it's really necessary. At 100 it will swap whenever it seems like a good idea to do so. Experiment however much you want since your settings will get put back to default (probably 60) when you reboot. The swappiness value is really a personal choice on a desktop. Basically it's a tradeoff between having a nice big disk cache (start open office, close it, open it again and it shows up instantly since it was still in cache) and not having to hit swap too often. If you really just want to see a bigger number next to "free memory" there's another setting to change called min_free_kbytes. It sets how much memory the kernel will keep for itself. This is almost certainly not something you want to change unless you're having problems with things living in kernel space not being able to allocate memory. Like all settings in /proc however it goes away on reboot, so go crazy.
CODE
echo 8192 > /proc/sys/vm/min_free_kbytes
Anyways, my take on all this is that any memory that's called "free" might as well be called "wasted." Linux takes the same view on this and thus tries to do something useful (cache) with any memory that would otherwise just sit there unused.
-John
QUOTE(JohnX @ Apr 18 2006, 12:46 AM)
Well, I read your comment and I was all set to come back and say "It's doing what it's supposed to be doing and you can't change it anyways, so don't worry about it," but then I did some reading.
For the Zaurus I can say with relative certainty that it really is freeing cache just fine exactly when it needs to. Linux is much more agressive about disk caching than other operating systems and it can make people used to other operating systems nervous to see so little memory marked as free. So, you really don't need to worry about it. The 2.6 kernel has some nice options for tuning the VM system through /proc/sys/vm/ , but 2.4 doesn't seem to have that kind of stuff exposed. If you're really concerned about it you might be able to do some basic tuning by looking at information on this page.
On your FC4 machine it's an entirely different case for two reasons:
1) The 2.6 kernel has all sorts of neat VM tuning parameters
2) The presence of swap
If you want less cache because you want to reduce how often it swaps out you can tune the "swappiness" value by doing:
Instead of 60 put different values between 0 and 100. At 0 the kernel will avoid swapping until it's really necessary. At 100 it will swap whenever it seems like a good idea to do so. Experiment however much you want since your settings will get put back to default (probably 60) when you reboot. The swappiness value is really a personal choice on a desktop. Basically it's a tradeoff between having a nice big disk cache (start open office, close it, open it again and it shows up instantly since it was still in cache) and not having to hit swap too often. If you really just want to see a bigger number next to "free memory" there's another setting to change called min_free_kbytes. It sets how much memory the kernel will keep for itself. This is almost certainly not something you want to change unless you're having problems with things living in kernel space not being able to allocate memory. Like all settings in /proc however it goes away on reboot, so go crazy.
Anyways, my take on all this is that any memory that's called "free" might as well be called "wasted." Linux takes the same view on this and thus tries to do something useful (cache) with any memory that would otherwise just sit there unused.
-John
For the Zaurus I can say with relative certainty that it really is freeing cache just fine exactly when it needs to. Linux is much more agressive about disk caching than other operating systems and it can make people used to other operating systems nervous to see so little memory marked as free. So, you really don't need to worry about it. The 2.6 kernel has some nice options for tuning the VM system through /proc/sys/vm/ , but 2.4 doesn't seem to have that kind of stuff exposed. If you're really concerned about it you might be able to do some basic tuning by looking at information on this page.
On your FC4 machine it's an entirely different case for two reasons:
1) The 2.6 kernel has all sorts of neat VM tuning parameters
2) The presence of swap
If you want less cache because you want to reduce how often it swaps out you can tune the "swappiness" value by doing:
CODE
echo 60 > /proc/sys/vm/swappiness
Instead of 60 put different values between 0 and 100. At 0 the kernel will avoid swapping until it's really necessary. At 100 it will swap whenever it seems like a good idea to do so. Experiment however much you want since your settings will get put back to default (probably 60) when you reboot. The swappiness value is really a personal choice on a desktop. Basically it's a tradeoff between having a nice big disk cache (start open office, close it, open it again and it shows up instantly since it was still in cache) and not having to hit swap too often. If you really just want to see a bigger number next to "free memory" there's another setting to change called min_free_kbytes. It sets how much memory the kernel will keep for itself. This is almost certainly not something you want to change unless you're having problems with things living in kernel space not being able to allocate memory. Like all settings in /proc however it goes away on reboot, so go crazy.
CODE
echo 8192 > /proc/sys/vm/min_free_kbytes
Anyways, my take on all this is that any memory that's called "free" might as well be called "wasted." Linux takes the same view on this and thus tries to do something useful (cache) with any memory that would otherwise just sit there unused.
-John
I'd have to say the same, there are XandrOS newbies over on their support forum worried about the same sort of thing on our desktops. All Linux systems seem to act this way; they'll show the memory available as in use, until you need it for something specific.
- Here's the thing. I'm using Hiro to read OESF, so I turn off all fastloading to keep the memory from "going yellow". I read your post, JonhX, look at memory, under 30MB in use, nearly 27 cached, rest free or buffers. So I fastload KDEPIM Calendar & Address, the two things I only ever have fastloaded. Memory pops straight to yellow, yet the memory applet shows that nearly 21MB is cache. If it's so aggresive about dumping cache, why do I have 21MB and a yellow memory condition? I can't help but think it should be dumping like mad if it running low on RAM. And it just sits there, utterly refusing to let go of even on byte of all that cache.
- I don't have a hard drive for swap, and just plain don't like the idea of using SD as swap, so swap is not currently an option, more's the pity.
- Maybe Opera is the culprit? Even if it is, I'd think the sytem would toss out cache rather than let itself grind to a halt because there's too little memory. I'd like to be able to indicate my preference. (shrug)
- Or maybe the memory applet is hitting yellow when it's not really that dire? I show yellow with over 5MB free, now that I've closed a couple of browser windows, yet it routinely shows green with 1 meg free when cache is larger. Is 37MB in use really that serious with 20 MB in cache & 5MB free? Perhaps I'm being paranoid? I just know I see yellow there very frequently, and I don't like it. (grin)
- Sounds like cache resizing is not readily doable. I thought not, but it didn't hurt to ask. I'll look for a little newer page on /proc and see what that turns up. Thanks for your time...
- I don't have a hard drive for swap, and just plain don't like the idea of using SD as swap, so swap is not currently an option, more's the pity.
- Maybe Opera is the culprit? Even if it is, I'd think the sytem would toss out cache rather than let itself grind to a halt because there's too little memory. I'd like to be able to indicate my preference. (shrug)
- Or maybe the memory applet is hitting yellow when it's not really that dire? I show yellow with over 5MB free, now that I've closed a couple of browser windows, yet it routinely shows green with 1 meg free when cache is larger. Is 37MB in use really that serious with 20 MB in cache & 5MB free? Perhaps I'm being paranoid? I just know I see yellow there very frequently, and I don't like it. (grin)
- Sounds like cache resizing is not readily doable. I thought not, but it didn't hurt to ask. I'll look for a little newer page on /proc and see what that turns up. Thanks for your time...
QUOTE
I have a hard time believing it really needs 20MB of cache at all times
Cache is more useful than free memory in most situations, especially when there's lots of it (and therefore the code you might want is already in memory, so the cache freeing and memory loading overheads are removed.)
QUOTE
why do I have 21MB and a yellow memory condition?
You attach too much importance to the colour produced by an applet. Just ignore it, or alter the source so that it calculates the 'free' memory using free + cached.
QUOTE
Or maybe the memory applet is hitting yellow when it's not really that dire? I show yellow with over 5MB free, now that I've closed a couple of browser windows, yet it routinely shows green with 1 meg free when cache is larger. Is 37MB in use really that serious with 20 MB in cache & 5MB free? Perhaps I'm being paranoid? I just know I see yellow there very frequently, and I don't like it. (grin)
Sounds a bit strange. Might be worth looking at the source to see what it's actually measuring.
Si
QUOTE(lardman @ Apr 19 2006, 07:12 PM)
QUOTE
I have a hard time believing it really needs 20MB of cache at all times
Cache is more useful than free memory in most situations, especially when there's lots of it (and therefore the code you might want is already in memory, so the cache freeing and memory loading overheads are removed.)
QUOTE
why do I have 21MB and a yellow memory condition?
You attach too much importance to the colour produced by an applet. Just ignore it, or alter the source so that it calculates the 'free' memory using free + cached.
QUOTE
Or maybe the memory applet is hitting yellow when it's not really that dire? I show yellow with over 5MB free, now that I've closed a couple of browser windows, yet it routinely shows green with 1 meg free when cache is larger. Is 37MB in use really that serious with 20 MB in cache & 5MB free? Perhaps I'm being paranoid? I just know I see yellow there very frequently, and I don't like it. (grin)
Sounds a bit strange. Might be worth looking at the source to see what it's actually measuring.
Si
or just enable swap and its always green
"If it's so aggresive about dumping cache, why do I have 21MB and a yellow memory condition? I can't help but think it should be dumping like mad if it running low on RAM."
That's the opposite of what I said. Linux is aggressive about building cache up. Whenever there's even a couple megs of free memory Linux works to fill it up with cache. This cache will get emptied *exactly* when it's needed and not a moment sooner. If you have 1MB free memory and start Opera, Linux will figure out what in cache is least valuable and drop it as Opera requests memory to start up.
"Or maybe the memory applet is hitting yellow when it's not really that dire? I show yellow with over 5MB free, now that I've closed a couple of browser windows, yet it routinely shows green with 1 meg free when cache is larger. Is 37MB in use really that serious with 20 MB in cache & 5MB free? Perhaps I'm being paranoid? I just know I see yellow there very frequently, and I don't like it. (grin)"
Bingo! Sounds like you're right on all counts. I'm willing to bet that the memory applet considers "free mem + cached mem" as "available" for determining when it should show as green or yellow. You really are just being paranoid.
That's the opposite of what I said. Linux is aggressive about building cache up. Whenever there's even a couple megs of free memory Linux works to fill it up with cache. This cache will get emptied *exactly* when it's needed and not a moment sooner. If you have 1MB free memory and start Opera, Linux will figure out what in cache is least valuable and drop it as Opera requests memory to start up.
"Or maybe the memory applet is hitting yellow when it's not really that dire? I show yellow with over 5MB free, now that I've closed a couple of browser windows, yet it routinely shows green with 1 meg free when cache is larger. Is 37MB in use really that serious with 20 MB in cache & 5MB free? Perhaps I'm being paranoid? I just know I see yellow there very frequently, and I don't like it. (grin)"
Bingo! Sounds like you're right on all counts. I'm willing to bet that the memory applet considers "free mem + cached mem" as "available" for determining when it should show as green or yellow. You really are just being paranoid.
- D'oh!
- Been letting it "go yellow" more often, since this thread, and it doesn't seem to ba ahuge deal. Even had 62MB in use at one point and Hiro pulled through. Stellar!
- Thanks JohnX...
- Been letting it "go yellow" more often, since this thread, and it doesn't seem to ba ahuge deal. Even had 62MB in use at one point and Hiro pulled through. Stellar!
- Thanks JohnX...
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.