Re: sync_file_range(SYNC_FILE_RANGE_WRITE) blocks?

[Rik van Riel <riel@redhat.com>]

On Mon, 2 Jun 2008 13:40:28 +0100 (BST)
Hugh Dickins <hugh@veritas.com> wrote:
> On Mon, 2 Jun 2008, Jens Axboe wrote:
> > 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

The problem with lots of CFQ requests is simpler.

If you look at balance_dirty_pages() you will see that it only
takes dirty and NFS unstable pages into account when checking
the dirty limit.  The pages that are in flight (under IO) are
not counted at all.

If you have 8192 CFQ requests and large streaming IO, most of
the IOs will be mergeable and it is possible to pin all of
memory in in-flight (PG_writeback - and other?) pages.

I suspect that balance_dirty_pages() will have to take the
writeback pages into account, though that may cause problems
with FUSE.  Maybe it should at least wait for some IO to
complete?

-- 
All rights reversed.