Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp648810imm; Thu, 4 Oct 2018 00:40:20 -0700 (PDT) X-Google-Smtp-Source: ACcGV601egY2AdiDMXEM/U55XZeKD+HjDnPg0Ik5B3Hjr2bfSVpFRL7YFFod3/WOJoafKF0GSJ5D X-Received: by 2002:a62:64d5:: with SMTP id y204-v6mr5411118pfb.187.1538638820308; Thu, 04 Oct 2018 00:40:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538638820; cv=none; d=google.com; s=arc-20160816; b=DohTl6cCvHdHUhzGC8DemtMAeL7CpzxePY31wHRSjRc34NUMSxaQXnUFioqy83JLpk gIhLu10Qf7L+scD1ACmfmflks+6pfVV8BxjU4PJtu5YSrMtu+ZWaZ0gLMOCGa5WSgCjU REg0AM7mOcuOOMha46Vv//zMu2o7hCNjGL7+qB6NjEpdoCbs5TfRZXPqsh9bu6RFzl4M ABIfVu3H2OWgZuFapUQR1UntzMmgtqUqlVhln3HZg8AWfbDN/njhStsJER3dar1upq3w rfwpZ0z5sJiCWSQ0ioyvgsIhzYgkBjN2X9xveE1xe1Vl9CcYgBj8+6X6t4Z7VeZIn7Oh MLYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=o0szz1Pc2QaepGXnWeAPSrOfIjg9H2RRSOEc9ZWHaJo=; b=MFfEuFk/KVb8kurn2ZL5x2dsBQt4r5u4/dwyjC8CVGVcQ58ayAslCSWA8UbKRgyiRA wGvOlJKxFlqcrEfBpKc8mMZxdHRk/kpHcwVkZgNjO7JL1VK3ilft6edvpv4vIRoBDboS Qzu3c6NEu2gGEWzULccZcSr0q9c49QgGUMf5dBTsf64LlIbVSWAxafP91AEjzMiYRkKS CR696CRK3kUNHe7RnQObWGErM3Q2/kKQFA4UnVVWy3MFIssG4AaFUDYyLyXVltcEPd7H xOzwBZ29etUtxyJZbTlKlGitg19VjWrrMn6TNKIQkWiBm1e6HZstuBdpbP/31Y0TauPs grhw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k29-v6si4473968pfk.194.2018.10.04.00.40.04; Thu, 04 Oct 2018 00:40:20 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727638AbeJDOaF (ORCPT + 99 others); Thu, 4 Oct 2018 10:30:05 -0400 Received: from mx2.suse.de ([195.135.220.15]:37444 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727269AbeJDOaF (ORCPT ); Thu, 4 Oct 2018 10:30:05 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id E9E5FAE4D; Thu, 4 Oct 2018 07:38:09 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 15E801E3614; Thu, 4 Oct 2018 09:38:09 +0200 (CEST) Date: Thu, 4 Oct 2018 09:38:09 +0200 From: Jan Kara To: Paolo Valente Cc: Oleksandr Natalenko , Jens Axboe , Linus Walleij , linux-block , linux-mmc , linux-mtd@lists.infradead.org, Pavel Machek , Ulf Hansson , Richard Weinberger , Artem Bityutskiy , Adrian Hunter , Jan Kara , Andreas Herrmann , Mel Gorman , Chunyan Zhang , linux-kernel , 'Paolo Valente' via bfq-iosched , Mark Brown Subject: Re: [PATCH] block: BFQ default for single queue devices Message-ID: <20181004073809.GD29482@quack2.suse.cz> References: <20181002124329.21248-1-linus.walleij@linaro.org> <05fdbe23-ec01-895f-e67e-abff85c1ece2@kernel.dk> <1eca41df95ff660eb247a3de666adeb4@natalenko.name> <6AF8CEDE-2720-4206-900A-1A9B914A8FF0@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6AF8CEDE-2720-4206-900A-1A9B914A8FF0@linaro.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 03-10-18 17:55:41, Paolo Valente wrote: > > On 03.10.2018 08:29, Paolo Valente wrote: > >> As also Linus Torvalds complained [1], people feel lost among > >> I/O-scheduler options. Actual differences across I/O schedulers are > >> basically obscure to non experts. In this respect, Linux-kernel > >> 'users' are way more than a few top-level distros that can afford a > >> strong performance team, and that, basing on the input of such a team, > >> might venture light-heartedly to change a critical component like an > >> I/O scheduler. Plus, as Linus Walleij pointed out, some users simply > >> are not distros that use udev. > > > > I feel a contradiction in this counter-argument. On one hand, there are lots of, let's call them, home users, that use major distributions with udev, so the distribution maintainers can reasonably decide which scheduler to use for which type of device based on the udev rule and common sense provided via Documentation/ by linux-block devs. Moreover, most likely, those rules should be similar or the same across all the major distros and available via some (systemd?) upstream. > > > > Let me basically repeat Mark's answer here, with my words. > > Unfortunately, facts mismatch with your optimistic view: after so many > years and concordant test results, only very few distributions > switched to bfq, no major distribution did (AFAIK). As I already > wrote, the reason is the one pointed out by Torvalds [1]. Do you want > a simple example? Take the last sentence in Jan's email in this > thread: "I *personally would* consider bfq a safer default ... but *I > don't feel too strongly* about it." And he is definitely a storage > expert. Yeah, but let me add that currently all our released kernels still use legacy block stack for SCSI by default and thus CFQ/deadline. And once we feel scsi-mq + BFQ is comparable enough for rotating disks (which may be after your latest changes, Andreas will be running some larger evaluation), we are going to switch to that instead of scsi + CFQ. So it's not like for us it is a question between deadline-mq and BFQ, it is rather between scsi + CFQ vs scsi-mq + BFQ. Honza -- Jan Kara SUSE Labs, CR