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
