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.

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 ). 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?