Re: [RFC] blk-mq and I/O scheduling

Path	csiph.com!eternal-september.org!feeder.eternal-september.org!aioe.org!bofh.it!news.nic.it!robomod
From	Andreas Herrmann <aherrmann@suse.com>
Newsgroups	linux.kernel
Subject	Re: [RFC] blk-mq and I/O scheduling
Date	Tue, 01 Dec 2015 08:50:01 +0100
Message-ID	<qANRf-6Ge-3@gated-at.bofh.it> (permalink)
References	<qwwci-Gn-11@gated-at.bofh.it> <qyOeK-29C-11@gated-at.bofh.it>
X-Original-To	Jens Axboe <axboe@kernel.dk>
MIME-Version	1.0
Content-Type	text/plain; charset=utf-8
Content-Disposition	inline
Content-Transfer-Encoding	8bit
User-Agent	Mutt/1.5.21 (2010-09-15)
Sender	robomod@news.nic.it
List-ID	<linux-kernel.vger.kernel.org>
X-Mailing-List	linux-kernel@vger.kernel.org
Approved	robomod@news.nic.it
Lines	60
Organization	linux.* mail to news gateway
X-Original-Cc	Christoph Hellwig <hch@lst.de>, linux-kernel@vger.kernel.org
X-Original-Date	Tue, 1 Dec 2015 08:43:41 +0100
X-Original-Message-ID	<20151201074341.GB12319@suselix.suse.de>
X-Original-References	<20151119120235.GA7966@suselix.suse.de> <56561049.7000201@kernel.dk>
X-Original-Sender	linux-kernel-owner@vger.kernel.org
Xref	csiph.com linux.kernel:1280621

Show key headers only | View raw

On Wed, Nov 25, 2015 at 12:47:21PM -0700, Jens Axboe wrote:
> On 11/19/2015 05:02 AM, Andreas Herrmann wrote:

 --8<--

> >The latter helped to improve performance for sequential reads and
> >writes. But it's not on a par with CFQ. Increasing the time slice is
> >suboptimal (as shown with the 2ms results, see below). It might be
> >possible to get better performance when further reducing the initial
> >time slice and adapting it up to a maximum value if there are
> >repeatedly pending requests for a CPU.
> >
> >After these observations and assuming that non-rotational devices are
> >most likely fine using blk-mq without I/O scheduling support I wonder
> >whether
> >
> >- it's really a good idea to re-implement scheduling support for
> >   blk-mq that eventually behaves like CFQ for rotational devices.
> >
> >- it's technical possible to support both blk-mq and CFQ for different
> >   devices on the same host adapter. This would allow to use "good old"
> >   code for "good old" rotational devices. (But this might not be a
> >   choice if in the long run a goal is to get rid of non-blk-mq code --
> >   not sure what the plans are.)
> >
> >What do you think about this?
> 
> Sorry I did not get around to properly looking at this this week,
> I'll tend to it next week. I think the concept of tying the idling
> to a specific CPU is likely fine, though I wonder if there are cases
> where we preempt more heavily and subsequently miss breaking the
> idling properly. I don't think we want/need cfq for blk-mq, but
> basic idling could potentially be enough. That's still a far cry
> from a full cfq implementation. The long term plans are still to
> move away from the legacy IO path, though with things like
> scheduling, that's sure to take some time.

FYI, I'll plan to send an updated patch later today.  

I've slightly changed it to allow specification of a time slice in µs
(instead of ms) and to extend it for a software queue when requests
were actually put into the hardware queue for this specific software
queue. This improved performance a little bit.

> That is actually where the mq-deadline work comes in. The
> mq-deadline work is missing a test patch to limit tag allocations,
> and a bunch of other little things to truly make it functional.
> There might be some options for folding it all together, with
> idling, as that would still be important on rotating storage going
> forward.


Thanks for you comments,

Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next | Find similar | Unroll thread

Thread

Re: [RFC] blk-mq and I/O scheduling Andreas Herrmann <aherrmann@suse.com> - 2015-12-01 08:50 +0100

csiph-web