lkml.org 
[lkml]   [2005]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: OOM fixes 2/5
Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
> On Thu, 2005-01-20 at 22:20 -0800, Andrew Morton wrote:
> > Andrea Arcangeli <andrea@suse.de> wrote:
> > >
> > > This is the forward port to 2.6 of the lowmem_reserved algorithm I
> > > invented in 2.4.1*, merged in 2.4.2x already and needed to fix workloads
> > > like google (especially without swap) on x86 with >1G of ram, but it's
> > > needed in all sort of workloads with lots of ram on x86, it's also
> > > needed on x86-64 for dma allocations. This brings 2.6 in sync with
> > > latest 2.4.2x.
> >
> > But this patch doesn't change anything at all in the page allocation path
> > apart from renaming lots of things, does it?
> >
> > AFAICT all it does is to change the default values in the protection map.
> > It does it via a simplification, which is nice, but I can't see how it
> > fixes anything.
> >
> > Confused.
>
>
> It does turn on lowmem protection by default. We never reached
> an agreement about doing this though, but Andrea has shown that
> it fixes trivial OOM cases.
>
> I think it should be turned on by default. I can't recall what
> your reservations were...?
>

Just that it throws away a bunch of potentially usable memory. In three
years I've seen zero reports of any problems which would have been solved
by increasing the protection ratio.

Thus empirically, it appears that the number of machines which need a
non-zero protection ratio is exceedingly small. Why change the setting on
all machines for the benefit of the tiny few? Seems weird. Especially
when this problem could be solved with a few-line initscript. Ho hum.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:09    [W:0.415 / U:0.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site