Messages in this thread | | | Date | Mon, 16 Jun 2008 21:54:06 -0700 | From | Andrew Morton <> | Subject | Re: sync_file_range(SYNC_FILE_RANGE_WRITE) blocks? |
| |
On Mon, 16 Jun 2008 16:53:51 -0400 Rik van Riel <riel@redhat.com> wrote:
> 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.
That would be totally busted. All that nr_writeback logic in there is very much supposed to handle under-writeback pages?
> 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?
Worried. One of us is missing something here.
| |