From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753218AbcCKNkg (ORCPT ); Fri, 11 Mar 2016 08:40:36 -0500 Received: from mail-qk0-f171.google.com ([209.85.220.171]:35284 "EHLO mail-qk0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752828AbcCKNkV (ORCPT ); Fri, 11 Mar 2016 08:40:21 -0500 Subject: Re: [PATCH RFC 09/22] block, cfq: replace CFQ with the BFQ-v0 I/O scheduler To: Christoph Hellwig References: <1454364778-25179-1-git-send-email-paolo.valente@linaro.org> <1454364778-25179-10-git-send-email-paolo.valente@linaro.org> <20160211222210.GC3741@mtj.duckdns.org> <8FDE2B10-9BD2-4741-917F-5A37A74E5B58@linaro.org> <20160217170206.GU3741@mtj.duckdns.org> <72E81252-203C-4EB7-8459-B9B7060029C6@linaro.org> <20160301184656.GI3965@htj.duckdns.org> <20160304173947.GA16764@infradead.org> <56D9CF97.7080005@gmail.com> <20160311111636.GB3450@infradead.org> Cc: Linus Walleij , Tejun Heo , Paolo Valente , Jens Axboe , Fabio Checconi , Arianna Avanzini , linux-block@vger.kernel.org, "linux-kernel@vger.kernel.org" , Ulf Hansson , Mark Brown From: "Austin S. Hemmelgarn" Message-ID: <56E2CA5F.8050901@gmail.com> Date: Fri, 11 Mar 2016 08:38:39 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160311111636.GB3450@infradead.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 160311-0, 2016-03-11), Outbound message X-Antivirus-Status: Clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016-03-11 06:16, Christoph Hellwig wrote: > On Fri, Mar 04, 2016 at 01:10:31PM -0500, Austin S. Hemmelgarn wrote: >> 1. This all started long before blk-mq hit mainline. > > Whoe cares? :) It wasn't intended as an argument for this continuing to be developed outside of blk-mq, but as an explanation of why the code exists as it does right now. >> 2. There's still a decent amount of block drivers that don't support blk-mq. >> Last time I looked (around the time 4.4 came out), I saw the following that >> either obviously don't support it, or are ambiguous as to whether they >> support it or not. Here's a list of just the ones I know are being used on >> existing systems running relatively recent kernel versions, not including > > There is no ambiguouity. You clearly named a few ones that aren't > converted, but also a lot of make_request_fn based drivers which don't > support any I/O scheduler. For someone reading the code there might not be any ambiguity, but from the perspective of someone who isn't reading the code (or even someone who has limited background in kernel programming), it very much is ambiguous, especially what does and doesn't support I/O scheduling in general. > But that whole point is that anything actively developed should move > over. Agreed.