Re: 2.5.74-mm3 OOM killer fubared ?

[Mikulas Patocka]

> > The problem, as I see it, is that you can dirty pages 10-15 times
> > faster than they can be written to disk. So, you will always
> > have the possibility of an OOM situation as long as you are I/O
> > bound.
>
> That's not a problem at all.  I think the VM never starts
> pageout IO on a page that doesn't look like it'll become
> freeable after the IO is done, so we simply shouldn't go
> into the OOM killer as long as there are pages waiting on
> pageout IO to finish.
>
> Once we really are OOM we shouldn't have pages in pageout
> IO.

What piece of code does prevent that?
As I see, OOM is triggered if no pages were freed in few loops. It
doesn't care about pages that are already being written or pages for which
write operation was started.

The only thing that prevents total oom when writing a lot of dirty pages
is blk_congestion_wait, but it's pretty unreliable because
1) it uses timeout
2) not all page writes go through block devices (NFS, NBD etc.)
blk_congestion_wait may be used for improving performance, but not for
ensuring stability.

> This is what I am doing in current 2.4-rmap and it seems
> to do the right thing in both the "heavy IO" and the "out
> of memory" corner cases.

I remember there was (and probably still is, only with smaller
probability) a similar bug in 2.2.

Mikulas