lkml.org 
[lkml]   [2005]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH][5/?] count writeback pages in nr_scanned
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).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:09    [W:0.116 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site