On Fri, Mar 22, 2013 at 2:20 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Fri, 22 Mar 2013 13:53:45 -0700, Raymond Jennings said:
The first heap would be synchronous requests such as reads and syncs that someone in userspace is blocking on.
The second is background I/O like writeback and readahead.
The same distinction that CFQ completely makes.
Again, this may or may not be a win, depending on the exact workload.
If you are about to block on a userspace read, it may make sense to go ahead and tack a readahead on the request "for free" - at 100MB/sec transfer and 10ms seeks, reading 1M costs the same as a seek. If you read 2M ahead and save 3 seeks later, you're willing. Of course, the *real* problem here is that how much readahead to actually do needs help from the VFS and filesystem levels - if there's only 600K more data before the end of the current file extent, doing more than 600K of read-ahead is a loss.
That sounds more like an argument for pushing readahead logic up into the fs and vfs levels. If it were up to me, linear/physical readahead would be disabled entirely. Speaking of which, I hear that tux3 is in the works to take more charge of bossing the block layer around.
Meanwhile, over on the write side of the fence, unless a program is specifically using O_DIRECT, userspace writes will get dropped into the cache and become writeback requests later on. So the vast majority of writes will usually be writebacks rather than syncronous writes.
So in many cases, it's unclear how much performance CFQ gets from making the distinction (and I'm positive that given a sufficient supply of pizza and caffeine, I could cook up a realistic scenario where CFQ's behavior makes things worse)...
Did I mention this stuff is tricky? :)