Messages in this thread | | | Date | Wed, 5 Jan 2005 15:49:35 -0200 | From | Marcelo Tosatti <> | Subject | Re: [PATCH][5/?] count writeback pages in nr_scanned |
| |
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 ;( - 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/
| |