BFQ: simple elevator

[Raymond Jennings]

On Fri, Mar 22, 2013 at 2:20 PM,  <Valdis.Kletnieks at 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? :)
>