From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760507AbcCEMSj (ORCPT ); Sat, 5 Mar 2016 07:18:39 -0500 Received: from mail-ob0-f181.google.com ([209.85.214.181]:36646 "EHLO mail-ob0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754249AbcCEMSb (ORCPT ); Sat, 5 Mar 2016 07:18:31 -0500 MIME-Version: 1.0 In-Reply-To: <20160304173947.GA16764@infradead.org> 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> Date: Sat, 5 Mar 2016 19:18:30 +0700 Message-ID: Subject: Re: [PATCH RFC 09/22] block, cfq: replace CFQ with the BFQ-v0 I/O scheduler From: Linus Walleij To: Christoph Hellwig , Ulf Hansson Cc: Tejun Heo , Paolo Valente , Jens Axboe , Fabio Checconi , Arianna Avanzini , linux-block@vger.kernel.org, "linux-kernel@vger.kernel.org" , Mark Brown Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Mar 5, 2016 at 12:39 AM, Christoph Hellwig wrote: > Btw, can someone explain why you guys waste so much time hacking and > arguing about a legacy codebase (old request code and I/O schedulers) > that everyone would really like to see disappear. Why don't you > spend your time on blk-mq where you have an entirely clean slate > for scheduling? Depends on what time horizon and target I'd say. Paolo was in contact with the MMC/SD subsystem maintainer Ulf Hansson. (e)MMC/SD are both synchronous command-response-based protocols, and as of today single-channel. So everone's smartphone and tablet etc are today single-channel. I don't know if there is even a protocol change coming to augment this, the only duct-tapeish solution I've heard about is command queueing which is basically a kind of pipelining of requests. So: large userbase in all things handheld. Yours, Linus Walleij