Re: [PATCH] modified segq for 2.5

[Andrew Morton <akpm@digeo.com>]

William Lee Irwin III wrote:
> 
> On Mon, Sep 09, 2002 at 03:58:06PM -0700, Andrew Morton wrote:
> > This logic is too global at present.  It really needs to be per-zone,
> > to fix an oom problem which you-know-who managed to trigger.  All
> > ZONE_NORMAL is dirty, we keep on getting woken up by IO completion in
> > ZONE_HIGHMEM, we end up scanning enough ZONE_NORMAL pages to conclude
> > that we're oom.  (Plus I reduced the maximum-scan-before-oom by 2.5x)
> > Then again, Bill had twiddled the dirty memory thresholds
> > to permit 12G of dirty ZONE_HIGHMEM.
> 
> This seemed to work fine when I just tweaked problem areas to use
> __GFP_NOKILL. mempool was fixed by the __GFP_FS checks, but
> generic_file_read(), generic_file_write(), the rest of filemap.c,
> slab allocations, and allocating file descriptor tables for poll() and
> select() appeared to generate OOM when it appeared to me that failing
> system calls with -ENOMEM was a better alternative than shooting tasks.

But clearly there is reclaimable pagecache down there; we just
have to wait for it.  No idea why you'd get an oom on ZONE_HIGHMEM,
but when I have a few more gigs I might be able to say.

Anyway, it's all too much scanning.

You'll probably find that segq helps by accident.  I installed
SEGQ (and the shrink-slab-harder-if-mapped-pages-are-enountered)
on my desktop here.  Initial indications are that SEGQ kicks butt.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/