Re: Linux I/O stack design question

[Werner Fischer <devlists@wefi.net>]

On Don, 2011-09-01 at 14:17 -0600, Jens Axboe wrote:
> On 2011-09-01 14:14, Werner Fischer wrote:
> >> 3) the fusion IO device driver can hook itself in where you put it, or
> >>    also up above the I/O scheduler (based on a module load option).
> > Oh wow, that sounds interesting. Does this mean that in this case (IO
> > device driver above the I/O scheduler) simply no I/O scheduler is used?
> 
> It'll hook in similarly to where stacked devices like md/dm do. So yes,
> it's bypassing the IO scheduler.
ok, i see.

> One note on that - this mode is going
> away in the future. 
Do you mean that this mode is going away in the future for the Fusion-io
driver or that generally no driver will be able to hook in there (also
the mtip32xx and nvmhci-express drivers you mention below)?

> You end up losing out on request merging, so write
> performance is hampered, for one.
> 
> The Micron pci-e mtip32xx driver does similarly, as does the
> nvmhci-express driver from Intel. IMHO it's largely due to
> inefficiencies in the IO stack, once we get those fixed, we should be
> getting back to the one true single IO mode for a driver.
With "one true single IO mode for a driver" you mean that every device
driver should sit and stay below the I/O scheduler?
Or do you mean that there should only be one single I/O scheduler? (in
the patch removing the anticipatory scheduler you suggested something
like this:
http://git.kernel.org/linus/492af6350a5ccf087e4964104a276ed358811458 )

> I consider the
> bypass setup a bit of a hack and work-around.

Regards,
Werner