Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934236AbcJZQFV (ORCPT ); Wed, 26 Oct 2016 12:05:21 -0400 Received: from mail-lf0-f51.google.com ([209.85.215.51]:40744 "EHLO mail-lf0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934159AbcJZQFI (ORCPT ); Wed, 26 Oct 2016 12:05:08 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler From: Paolo Valente In-Reply-To: <3ebadbb8-9ac2-851a-66f9-c9db25713695@kernel.dk> Date: Wed, 26 Oct 2016 18:04:56 +0200 Cc: Christoph Hellwig , Arnd Bergmann , Bart Van Assche , Jan Kara , Tejun Heo , linux-block@vger.kernel.org, Linux-Kernal , Ulf Hansson , Linus Walleij , Mark Brown , Hannes Reinecke , grant.likely@secretlab.ca, James.Bottomley@hansenpartnership.com Message-Id: <38156FA7-9A66-44DC-8D0C-28F149D1E49B@linaro.org> References: <1477474082-2846-1-git-send-email-paolo.valente@linaro.org> <20161026113443.GA13587@quack2.suse.cz> <4ed3e291-b3e5-5ee3-6838-58644bd3d99b@sandisk.com> <12386463.fJy0cVexVD@wuerfel> <20161026152955.GA21262@infradead.org> <3ebadbb8-9ac2-851a-66f9-c9db25713695@kernel.dk> To: Jens Axboe X-Mailer: Apple Mail (2.3124) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id u9QG5W8R001625 Content-Length: 2206 Lines: 58 > Il giorno 26 ott 2016, alle ore 17:32, Jens Axboe ha scritto: > > On 10/26/2016 09:29 AM, Christoph Hellwig wrote: >> On Wed, Oct 26, 2016 at 05:13:07PM +0200, Arnd Bergmann wrote: >>> The question to ask first is whether to actually have pluggable >>> schedulers on blk-mq at all, or just have one that is meant to >>> do the right thing in every case (and possibly can be bypassed >>> completely). >> >> That would be my preference. Have a BFQ-variant for blk-mq as an >> option (default to off unless opted in by the driver or user), and >> not other scheduler for blk-mq. Don't bother with bfq for non >> blk-mq. It's not like there is any advantage in the legacy-request >> device even for slow devices, except for the option of having I/O >> scheduling. > > It's the only right way forward. blk-mq might not offer any substantial > advantages to rotating storage, but with scheduling, it won't offer a > downside either. And it'll take us towards the real goal, which is to > have just one IO path. ok > Adding a new scheduler for the legacy IO path > makes no sense. I would fully agree if effective and stable I/O scheduling would be available in blk-mq in one or two months. But I guess that it will take at least one year optimistically, given the current status of the needed infrastructure, and given the great difficulties of doing effective scheduling at the high parallelism and extreme target speeds of blk-mq. Of course, this holds true unless little clever scheduling is performed. So, what's the point in forcing a lot of users wait another year or more, for a solution that has yet to be even defined, while they could enjoy a much better system, and then switch an even better system when scheduling is ready in blk-mq too? For example, currently, opening a terminal on a 50KIOPS SSD with cfq, deadline or noop, if there happens to be some background workload, takes *more* time than opening the same terminal on a 1KIOPS HDD with the same background workload, but with BFQ. Does this make any sense? > Adding one for blk-mq and phasing out the old path is > what we need to do. > Yes, as the ultimate goal. Thanks, Paolo > -- > Jens Axboe >