Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933349AbcJZPN6 (ORCPT ); Wed, 26 Oct 2016 11:13:58 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:52942 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932165AbcJZPNz (ORCPT ); Wed, 26 Oct 2016 11:13:55 -0400 From: Arnd Bergmann To: Bart Van Assche Cc: Jan Kara , Christoph Hellwig , Paolo Valente , Jens Axboe , Tejun Heo , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, ulf.hansson@linaro.org, linus.walleij@linaro.org, broonie@kernel.org, hare@suse.de, grant.likely@secretlab.ca, James.Bottomley@hansenpartnership.com Subject: Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler Date: Wed, 26 Oct 2016 17:13:07 +0200 Message-ID: <12386463.fJy0cVexVD@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <4ed3e291-b3e5-5ee3-6838-58644bd3d99b@sandisk.com> References: <1477474082-2846-1-git-send-email-paolo.valente@linaro.org> <20161026113443.GA13587@quack2.suse.cz> <4ed3e291-b3e5-5ee3-6838-58644bd3d99b@sandisk.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:DYCafeXF5V64yxVHDU6o7C35asPQgwoXG8hFoVT/12JoE1XR/Ea BXakp7eU9RTJdFirROWRrL++uLaFgd0OH2DOvnfMuz2xzheAYnLQEhsPgCL+wAcVQ/Tqrgz MFivbGe0XaYBZEUbGFVTI78LZC1noHYvroyRCF4jMwYKcLOaR8mp0VamzkXpAZ8gtifeDS6 vs5yEVJuRz6nQDTyhYJhg== X-UI-Out-Filterresults: notjunk:1;V01:K0:7b7RtVVnw+I=:QapFA73bjyxNFpdbrpq/bp 8rvqcmWJSA/QTnUnsVRAUisqmkogrDnAbzFH1Rm99K6jap38Cq+w+1ELhXxZWqGQfC4Ylg6SU 07IU9QjrLqdIrs3mVjRxqnK7rt5DKj6/EvoTB3q+k3tgUgJPdgcLVrFyO81RXr/YXpoFUNnNT BPOF93tY5n4AQwxsAMpHGC1As0r8yhTCnrK4CMWLYHsZSx52WNZOWQ3FDdJT9V63datVZFNsz 8Cc7SpGygFuu4siWS/BBeDFBymAjpyXqmkAmdDIDs9KaFLeVjhpm0gvZswEwbylTJ93adSfjx IlNSczqU3b1ks1iaZE2EryXKJJjCXWmxAPFcJQZExQQeVLUQIVYtmGLT5u5LjodsNAeMW89yY V66+j5SFRlTQr0ekCSJjKP1LF0AUKiojFfijmY6OP7PIV67Ma9QEEP+JYwtqBT2EiQmfdj/Qi RSvDyjRF63jZ5wAIfUVCvtpQHaeQ3UKsvcQoAiBezWQT+ATL6hkYy+Ti2NsbXOQDhPv86Gs05 t4I2kNEhqJS0a4StQnmjIR3/q96qF9PNvc1h7mJAVj1ZiUWpw9rlVSJLMIXRqr/vS9TWkdQxw edO6ru1xcKWiEnlwv7nhv0Ce1t7SPqc6VEmhc8rGW7DggY2V7swYgl/kggblNTzAmLt5ATNaB GA8viaEh9+NcQRwxIA06MgqzPLjd8LyPMNpcx0/Fb0eugGHS9htqrTb/hS5SCw259dXxcdRY4 RZMh4qVXYLg12+Gt Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1518 Lines: 33 On Wednesday, October 26, 2016 8:05:11 AM CEST Bart Van Assche wrote: > On 10/26/2016 04:34 AM, Jan Kara wrote: > > On Wed 26-10-16 03:19:03, Christoph Hellwig wrote: > >> Just as last time: > >> > >> big NAK for introducing giant new infrastructure like a new I/O scheduler > >> for the legacy request structure. > >> > >> Please direct your engergy towards blk-mq instead. > > > > Christoph, we will probably talk about this next week but IMO rotating > > disks and SATA based SSDs are going to stay with us for another 15 years, > > likely more. For them blk-mq is no win, relatively complex IO scheduling > > like CFQ or BFQ does is a big win for them in some cases. So I think IO > > scheduling (and thus place for something like BFQ) is going to stay with us > > for quite a long time still. So are we going to add hooks in blk-mq to > > support full-blown IO scheduling at least for single queue devices? Or how > > else do we want to support that HW? > > Hello Jan, > > Having two versions (one for non-blk-mq, one for blk-mq) of every I/O > scheduler would be a maintenance nightmare. Has anyone already analyzed > whether it would be possible to come up with an API for I/O schedulers > that makes it possible to use the same I/O scheduler for both blk-mq and > the traditional block layer? 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). Arnd