I took a cue from Kyle and checked out the vm.overcommit_memory and vm.overcommit_ratio settings in sysctl.conf, but I don't have anything too conclusive to offer.
The original context was the whole X-in-1Mb effect that I get with this Pentium, a feat that I certainly can’t take credit for, and don’t dare try to explain.
In hopes of further slimming the memory needs, I wrangled with the two overcommit settings, but to be honest, I didn’t see much in the way of an improvement … or even a change, really.
What I would like to see happen is for the system to cram as much as possible into memory before spilling into swap — something that I believe I can control by adjusting the vm.swappiness setting.
Adjusting the overcommit ones didn’t seem to affect memory usage; they did however seem to drag program startups slightly. I can’t say for certain they would have that effect on all software on all systems. Remember that most of the software I use fits into less than a megabyte apiece anyway. So manhandling the overcommit variables might change memory use in an unnoticeable way.
I would be curious to see if those variables have any effect on any other systems. Perhaps I’ll try them on other machines and try to measure the effect. If you beat me to it, let me know how it goes.
I am a bit confused as to what exactly you are trying to succeed?
From what I have read (http://opsmonkey.blogspot.com/2007/01/linux-memory-overcommit.html) about those settings, all they look like they are useful for (generally) is preventing the kernel from randomly killing processes when there is no more memory available. Instead, if there is a lack of memory they should attempt to handle it themselves. I would suggest setting vm.overcommit_memory to 2, which means memory allocations can fail, and as such programs have the chance to fall over gracefully.
The other option appears to be to set the percentage of memory available for the applications to allocated, the rest of which is free, either for other applications which will only need memory every so often (your system would not be very useful if there was no memory available to run the halt command or run screen to reattach to a session :P). The other option, as mentioned in the article, is to ‘reserve’ memory to be used for the filesystem cache.
Either way, I am still amazed (and intrigued) that you are (still) trying to squeeze every last drop of performance out of this machine! Keep it up! 😀 Have you looked into uclibc (and the like) which is the base of Slitaz?
Well, to be honest, those settings fall a little ways beyond my normal area of “expertise,” so I’m not really sure my expectations matched the actual intentions.
I saw the same threads probably, that mentioned how programs were killed. Judging by Kyle’s note and by the kernel documentation, I was hoping that those settings would shave the amount of memory allocated to each program.
But I was probably wrong from the start. Which is okay with me; I’ve been wrong so many times with Linux that it feels weird to be right.