On 8/11/06, Roderick <
r.ford@cox.net> 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" <viriketo@gmail.com>
> 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 )) :
<begin quote>
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...]
<end quote>
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
---------------------------------------------------
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
(text/plain)