On 8/11/06, Roderick wrote: > > Wow! did you guys know that you could switch off the overcommitment of > memory? This posting was recently from the Plan9 o.s. mailing list. > Thought you all might want this juicy tidbit of Linux hacking info. > Rod > -- > Roderick Ford, Software Engineer > Open Design Alliance > http://www.opendesign.com/ > > ------- Forwarded message ------- > From: "Lluís Batlle i Rossell" > To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> > Cc: > Subject: Re: [9fans] Swap considered harmful (Sorry) > Date: Mon, 07 Aug 2006 10:49:05 -0700 > > Ronald G Minnich wrote: > > Charles Forsyth wrote: > > > >> > >> Linux apparently takes the Atlas approach and thrashes on demand. > >> > > > > until it starts killing random processes. Usually the wrong one. But, > > hey, heuristics, right? > > Maybe you already know, but by chance I got into the linux malloc(3) > manpage, and I found its BUGS section: > > > BUGS > By default, Linux follows an optimistic memory allocation strategy. > This means that when malloc() returns non-NULL there is no guarantee > that the memory really is available. This is a really bad bug. In case it > turns out that the system is out of memory, one or more processes will > be killed by the infamous OOM killer. In case Linux is employed under > circumstances where it would be less desirable to suddenly lose some > randomly picked processes, and moreover the kernel version is sufficiently > recent, one can switch off this overcommitting behavior using a command > like > # echo 2 > /proc/sys/vm/overcommit_memory > > > > > > > --------------------------------------------------- > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > To subscribe, unsubscribe, or to change you mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > I was wondering, why [gnu/] Linux doesn't just use a "safer" implementation by default. I started doing some searches, using Google and yahoo, and it turns out that there is way more to it, than what I would have guessed. Apparently there are some good reasons why, one does not always necessarily prefer the last option discussed here, in this excerpt from a discussion list (( This quote is from the initial post of a big thread about "...strict VM opvercommit accounting...", see http://marc2.theaimsgroup.com/?l=linux-kernel&m=113592878502058&w=2 )) : diff -ruN linux-2.4.33-pre1/Documentation/vm/overcommit-accounting \ linux-2.4.33-pre1-memA/Documentation/vm/overcommit-accounting --- linux-2.4.33-pre1/Documentation/vm/overcommit-accounting Wed Dec 31 16:00:00 1969 +++ linux-2.4.33-pre1-memA/Documentation/vm/overcommit-accounting Thu Dec 29 20:39:30 \ 2005 @@ -0,0 +1,70 @@ +* This describes the overcommit management facility in the latest kernel + tree (FIXME: actually it also describes the stuff that isnt yet done) + +The Linux kernel supports four overcommit handling modes + +0 - Heuristic overcommit handling. Obvious overcommits of + address space are refused. Used for a typical system. It + ensures a seriously wild allocation fails while allowing + overcommit to reduce swap usage + +1 - No overcommit handling. Appropriate for some scientific + applications + +2 - (NEW) strict overcommit. The total address space commit + for the system is not permitted to exceed swap + half ram. + In almost all situations this means a process will not be + killed while accessing pages but only by malloc failures + that are reported back by the kernel mmap/brk code. + +3 - (NEW) paranoid overcommit The total address space commit + for the system is not permitted to exceed swap. The machine + will never kill a process accessing pages it has mapped + except due to a bug (ie report it!) + +Gotchas +------- [...snip...] I would think that, as RAM gets cheaper, folks would want to consider using something that is "safer", even though it requires more RAM to get a certain amount (X) of work done. However, during the searching on Google (and yahoo) that I did while trying to barely scratch the surface, it appears that there is a lot more to it, than I would ever have guessed... I don't have time right now to pursue this any further just out of curiosity. If anyone has any comments, they would be welcome... (but I do not promise to read them all, 100%, if they are anywhere near the seeming avalanche of stuff that I started finding, when I started googling...) -- Mike Schwartz Glendale AZ schwartz@acm.org Mike.L.Schwartz@gmail.com