Re: [PATCH] modified segq for 2.5

Andrew Morton
2002-09-10T00:02:37Z

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.