Messages in this thread | | | Date | Wed, 5 Jan 2005 19:06:51 +0100 | From | Andrea Arcangeli <> | Subject | Re: [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/
| |