Messages in this thread | | | Date | Mon, 2 Jun 2008 09:50:19 -0700 | From | Andrew Morton <> | Subject | Re: sync_file_range(SYNC_FILE_RANGE_WRITE) blocks? |
| |
On Mon, 2 Jun 2008 13:43:20 +0200 Jens Axboe <jens.axboe@oracle.com> wrote:
> On Sun, Jun 01 2008, Andrew Morton wrote: > > > > I expect major users of this system call will be applications which do > > > > small-sized overwrites into large files, mainly databases. That is, > > > > once the application developers discover its existence. I'm still > > > > getting expressions of wonder from people who I tell about the > > > > five-year-old fadvise(). > > > > > > Hey, you have one user now, its called s2disk. But for this call to be > > > useful, we'd need asynchronous variant... is there such thing? > > > > 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?
The VFS did screw up a couple of times with unbounded queues. It did get fixed and it is a design objective for the writeback code to _not_ depend upon request exhaustion for proper behaviour.
But it hasn't had a large amount of testing with unbounded queues and there may still be problems in there.
| |