[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160210194715.GA324@x4>
Date: Wed, 10 Feb 2016 20:47:15 +0100
From: Markus Trippelsdorf <markus@...ppelsdorf.de>
To: Andreas Herrmann <aherrmann@...e.com>
Cc: Christoph Hellwig <hch@....de>, Jens Axboe <axboe@...nel.dk>,
linux-kernel@...r.kernel.org,
Johannes Thumshirn <jthumshirn@...e.de>,
Jan Kara <jack@...e.cz>, linux-block@...r.kernel.org,
linux-scsi@...r.kernel.org, Hannes Reinecke <hare@...e.de>
Subject: Re: [RFC PATCH v2] blk-mq: Introduce per sw queue time-slice
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
Powered by blists - more mailing lists