Re: 2.5.74-mm3 OOM killer fubared ?

[Andrew Morton]

"Miquel van Smoorenburg" <[e-mail]> wrote:
>
> I was running 2.5.74 on our newsfeeder box for a day without
> problems (and 2.5.72-mm2 for weeks before that).

And how was 2.5.72-mm2 performing, generally?

> Now with 2.5.74-mm3 (booted 11 hours ago) it keeps killing processes
> for no apparent reason:
> ...
> I notice that in -mm3 this was deleted relative to -vanilla:
> 
> -
> -       /*
> -        * Enough swap space left?  Not OOM.
> -        */
> -       if (nr_swap_pages > 0)
> -               return;
>   
> .. is that what causes this?

Yes.  That was a "hmm, I wonder what happens if I do this" patch.  It's
interesting that we're going down that code path.

Is your INND configured to use the strange mmap(MAP_SHARED) of a blockdev
thing?   That could explain the scanning hysteria.

> Related mm question - this box is a news server, which does a lot
> of streaming I/O, and also keeps a history database open. I have the
> idea that the streaming I/O evicts the history database hash and
> index file caches from memory, which I do not want. Any chance of
> a control on a filedescriptor that tells it how persistant to be
> in caching file data ? E.g. a sort of "nice" for the cache, so that
> I could say that streaming data may be flushed from buffers/cache
> earlier than other data (where the other data would be the
> database files) ?

Makes sense.  We can use posix_fadvise(POSIX_FADV_NOREUSE) as a hint to
tell the VM/VFS to throw away old pages.  I'll take a look at that.