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

[Marcelo Tosatti <marcelo.tosatti@cyclades.com>]

On Wed, Jan 05, 2005 at 01:50:51PM -0500, Rik van Riel wrote:
> On Wed, 5 Jan 2005, Andrea Arcangeli wrote:
> 
> >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.
> 
> Or the IO that just finished, finished for pages in
> another memory zone, or pages we won't scan again in
> our current go-around through the VM...

Thing is there is no distinction between pages which have been written out 
for what purpose at the block level. 

One can conjecture the following: per-zone waitqueue to be awakened from 
end_page_writeback() (for PG_reclaim pages only of course), and a function
to wait on the perzone waitqueue:

 wait_vm_writeback (zone, timeout);

Instead of the current blk_congestion_wait() on try_to_free_pages/balance_pgdat.

It will probably slow the reclaiming procedure in general, though, and has
other side effects, but its the only way of strictly following VM writeback
progress from VM reclaiming routines.

Does it make any sense?

> >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).
> 
> Indeed ;(