Re: [RFC PATCH 00/20] dm-crypt: parallel processing

[Vivek Goyal <vgoyal@redhat.com>]

On Tue, Aug 21, 2012 at 11:23:40AM -0700, Tejun Heo wrote:

[..]
> > > 1) Last two patches (19/20) provides sorting of IO requests, this
> > > logically should be done in IO scheduler.
> > > 
> > > I don't think this should be in dmcrypt, if scheduler doesn't work
> > > properly, it should be fixed or tuned for crypt access pattern.
> 
> I kinda agree but preserving (not strictly but at least most of the
> time) issuing order across stacking driver like dm probably isn't a
> bad idea.  I *think* the direction block layer should be headed is to
> reduce the amount of work it does as the speed and characteristics of
> underlying devices improve.  We could afford to do a LOT of things to
> better cater to devices with spindles but the operating margin
> continues to become narrower.  Jens, Vivek, what do you guys think?

I think we can make various block layer functionalities optional and
faster drivers can choose which ones do they want. For example,
"queue/nomerges" disables merging. May be another sys tunable or a queue
flag (which driver provides at the time of registration) for "nosorting"
can be used to reduce the amount of work block layer does.

That way slower devices can still make use of loaded block layer and
faster devices can opt out of those features.

Thanks
Vivek