Re: [PATCH] modified segq for 2.5

Andrew Morton
2002-09-10T01:13:43Z

William Lee Irwin III wrote:
>
> William Lee Irwin III wrote:
> >> 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.
>
> On Mon, Sep 09, 2002 at 05:02:31PM -0700, Andrew Morton wrote:
> > 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.
>
> Well, there was no swap, and most things were dirty. Not sure about the
> rest. I was miffed by "Something tells it there's no memory and it
> shoots tasks instead of returning -ENOMEM to userspace in a syscall?"
> Saying "no" to the task allocating seems better than shooting tasks to
> me. out_of_memory() being called too early sounds bad, too, though.

If there is dirty memory or memory under writeback then
going oom or returning NULL is a bug.

It's just a search problem, and not a very complex one. Per-zone
dirty accounting, per-zone throttling and a separate known-to-be-unreclaimable list should fix it up. Give me
a few days to find a motivated moment...