Re: [RFC PATCH v2] blk-mq: Introduce per sw queue time-slice

[Markus Trippelsdorf]

On 2016.02.10 at 20:34 +0100, Andreas Herrmann wrote:
> On Tue, Feb 09, 2016 at 06:41:56PM +0100, Markus Trippelsdorf wrote:
> > > Recently Johannes sent a patch to enable scsi-mq per driver, see
> > > http://marc.info/?l=linux-scsi&m=145347009631192&w=2
> > > 
> > > Probably that is a good solution (at least in the short term) to allow
> > > users to switch to blk-mq for some host adapters (with fast storage
> > > attached) but to stick to legacy stuff on other host adapters with
> > > rotary devices.
> > 
> > I don't think that Johannes' patch is a good solution.
> 
> Why? Because it's not per device?

Yes. Like Christoph said in his reply to the patch: »The host is simply
the wrong place to decide these things.«

> > The best solution for the user would be if blk-mq could be toggled
> > per drive (or even automatically enabled if queue/rotational == 0).
> 
> Yes, I aggree, but ...
> 
> > Is there a fundamental reason why this is not feasible?
> 
> ... it's not possible (*) with the current implementation.
> 
> Tag handling/command allocation differs. Respective functions are set
> per host.
> 
> (*) Or maybe it's possible but just hard to achieve and I didn't look
> long enough into relevant code to get an idea how to do it.
> 
> > Your solution is better than nothing, but it requires that the user
> > finds out the drive <=> host mapping by hand and then runs something
> > like: 
> > echo "250" > /sys/devices/pci0000:00/0000:00:11.0/ata2/host1/target1:0:0/1:0:0:0/block/sdb/mq/0/time_slice_us
> > during boot for spinning rust drives...
> 
> Or it could automatically be set in case of rotational device.
> (Once we know for sure that it doesn't cause performance degradation.)

Yes, this sound like a good idea.

But, if I understand things correctly, your patch is only an interim
solution until proper I/O scheduler support gets implemented for blk-mq, no?

-- 
Markus