Messages in this thread | | | Date | Mon, 2 Jun 2008 13:40:28 +0100 (BST) | From | Hugh Dickins <> | Subject | Re: sync_file_range(SYNC_FILE_RANGE_WRITE) blocks? |
| |
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 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
| |