On Mon, 2 Jun 2008, Jens Axboe wrote:
quoted text
> On Sun, Jun 01 2008, Andrew Morton wrote:
> > 
> > Well if you're asking the syscall to shove more data into the block
> > layer than it can concurrently handle, sure, the block layer will
> > block.  It's tunable...
> 
> Ehm, lets get the history right, please :-)
> 
> The block layer pretty much doesn't care about how large the queue
> size is, it's largely at 128 to prevent the vm from shitting itself
> like it has done in the past (and continues to do I guess, though
> your reply leaves me wondering).
> 
> So you think the vm will be fine with a huge number of requests?
> It wont go nuts scanning and reclaiming, wasting oodles of CPU
> cycles?

Interesting.  I wonder.  I may be quite wrong (Cc'ed Rik and Lee
who I think are currently most in touch with what goes on there),
but my impression is that whereas vmscan.c takes pages off LRU
while it's doing writeback on them, and arranges for them to go
back to the reclaimable tail of the LRU once writeback completes
(the rotate reclaimable business), pages under writeback which
it did not itself initiate will get put back on LRU at the head
(with write completion still pending).

If unbounded queues turn out to be viable in other respects
(which would be very attractive for SYNC_PAGE_RANGE_WRITE), even
if not, then maybe shrink_page_list needs to be able to take pages
already under Writeback off the LRU and set them Reclaimable.

Hugh
--
unsubscribe notice
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/