Re: [PATCH][5/?] count writeback pages in nr_scanned

[Andrea Arcangeli <andrea@suse.de>]

On Wed, Jan 05, 2005 at 02:08:59AM -0800, Andrew Morton wrote:
> Rik van Riel <riel@redhat.com> wrote:
> >
> > Still untested, but posting the concept here anyway, since this
> >  could explain a lot...
> > 
> >  OOM kills have been observed with 70% of the pages in lowmem being
> >  in the writeback state.  If we count those pages in sc->nr_scanned,
> >  the VM should throttle and wait for IO completion, instead of OOM
> >  killing.
> > 
> >  Signed-off-by: Rik van Riel <riel@redhat.com>
> > 
> >  --- linux-2.6.9/mm/vmscan.c.screclaim	2005-01-03 12:17:56.547148905 -0500
> >  +++ linux-2.6.9/mm/vmscan.c	2005-01-03 12:18:16.855965416 -0500
> >  @@ -376,10 +376,10 @@
> > 
> >    		BUG_ON(PageActive(page));
> > 
> >  +		sc->nr_scanned++;
> >    		if (PageWriteback(page))
> >    			goto keep_locked;
> > 
> >  -		sc->nr_scanned++;
> 
> Patch looks very sane.  It in fact restores that which we were doing until
> 12 June 2004, when the rampant `struct scan_control' depredations violated
> the tree.

Agreed.

Another unrelated problem I have in this same area and that can explain
VM troubles at least theoretically, is that blk_congestion_wait is
broken by design. First we cannot wait on random I/O not related to
write back. Second blk_congestion_wait gets trivially fooled by
direct-io for example. Plus the timeout may cause it to return too early
with slow blkdev.

blk_congestion_wait is a fundamental piece to get oom detection right
during writeback and unfortunately it's fundamentally fragile in 2.6
(this as usual wasn't the case in 2.4).