From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Date: Wed, 03 Oct 2018 13:49:25 +0200 From: Oleksandr Natalenko To: Paolo Valente Cc: 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 In-Reply-To: References: <20181002124329.21248-1-linus.walleij@linaro.org> <05fdbe23-ec01-895f-e67e-abff85c1ece2@kernel.dk> Message-ID: <1eca41df95ff660eb247a3de666adeb4@natalenko.name> List-ID: Hi. 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. On another hand, the users of embedded devices, mentioned by Linus, should already know what scheduler to choose because dealing with embedded world assumes the person can decide this on their own, or with the help of abovementioned udev scripts and/or Documentation/ as a reference point. So I see no obstacles here, and the choice to rely on udev by default sounds reasonable. The question that remain is whether it is really important to mount a root partition while already using some specific scheduler? Why it cannot be done with "none", for instance? > So, probably 99% of Linux-kernel users will just stick to the default > I/O scheduler, mq-deadline, assuming that the algorithm by which that > scheduler was chosen was not "pick the scheduler with the longest > name", but "pick the best scheduler for most cases". The problem is > that, for single-queue devices with a speed below 400/500 KIOPS, the > default scheduler is apparently incomparably worse than bfq in terms > of responsiveness and latency for time-sensitive applications [2], and > in terms of throughput reached while controlling I/O [3]. And, in all > other tests ran so far, by any entity or group I'm aware of, bfq > results basically on par with or better than mq-deadline. And that's why major distributions are likely to default to BFQ via udev. No one argues with BFQ superiority here ☺. > So, I do understand your need for conservativeness, but, after so much > evidence on single-queue devices, and so many years! :), what's the > point in keeping Linux worse for virtually everybody, by default? From my point of view this is not a conservative approach at all. On contrary, offloading decisions to userspace aligns pretty well with recent trends like pressure metrics/userspace OOM killer, eBPF etc. The less unnecessary logic the kernel handles, the more flexibility it affords. -- Oleksandr Natalenko (post-factum) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=0.5 required=3.0 tests=DKIM_ADSP_ALL,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 91390C00449 for ; Wed, 3 Oct 2018 11:56:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 467832064A for ; Wed, 3 Oct 2018 11:56:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=natalenko.name header.i=@natalenko.name header.b="EuEHY/cY" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 467832064A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=natalenko.name Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727287AbeJCSok (ORCPT ); Wed, 3 Oct 2018 14:44:40 -0400 Received: from vulcan.natalenko.name ([104.207.131.136]:10932 "EHLO vulcan.natalenko.name" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726809AbeJCSok (ORCPT ); Wed, 3 Oct 2018 14:44:40 -0400 X-Greylist: delayed 427 seconds by postgrey-1.27 at vger.kernel.org; Wed, 03 Oct 2018 14:44:38 EDT Received: from mail.natalenko.name (vulcan.natalenko.name [IPv6:fe80::5400:ff:fe0c:dfa0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by vulcan.natalenko.name (Postfix) with ESMTPSA id C7F2E41EB8D; Wed, 3 Oct 2018 13:49:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natalenko.name; s=dkim-20170712; t=1538567366; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CkKmYlWkHHemij050YscC/BErDSwO4FtNfcOIl5gQkc=; b=EuEHY/cYMuOi+aOfJokyZR29b/FGnGeePiyerF5ymgSifzTVc0yO85SwHpSGbQBqcbjiGB hiH/tOJhpMrSF/L1p3snxKUxnx4wh4a8kSxoKkiAdWpisQskToqcmtptncUNvLd4Egue3/ 36QiZQ6csy4sizWhfLcC9Gzj+coREMw= DMARC-Filter: OpenDMARC Filter v1.3.2 vulcan.natalenko.name C7F2E41EB8D Authentication-Results: vulcan.natalenko.name; dmarc=fail (p=none dis=none) header.from=natalenko.name MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 03 Oct 2018 13:49:25 +0200 From: Oleksandr Natalenko To: Paolo Valente Cc: 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 In-Reply-To: References: <20181002124329.21248-1-linus.walleij@linaro.org> <05fdbe23-ec01-895f-e67e-abff85c1ece2@kernel.dk> Message-ID: <1eca41df95ff660eb247a3de666adeb4@natalenko.name> X-Sender: oleksandr@natalenko.name User-Agent: Roundcube Webmail/1.3.7 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=natalenko.name; s=arc-20170712; t=1538567366; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CkKmYlWkHHemij050YscC/BErDSwO4FtNfcOIl5gQkc=; b=iV+JrVPuRATxL3Lb65vWzCaET42VaHjatxRwHcOUCMUTVOF3aOxEL+XfToQ8TSAjpbfSEC WrCire5al3/9T/vqp40A13ctVvT5cVv4ad/3GNGUYK6OWC9MLUcmvTK3S03REHpO82qrZy Kly+WrHIOg+fQ8BWRfI8ZWzl39+X0dg= ARC-Seal: i=1; s=arc-20170712; d=natalenko.name; t=1538567366; a=rsa-sha256; cv=none; b=DdvfF3JSdcwxXnR5u7+paHEE6T688DmWBgcXogiWZbojDdUM4hND8Wqm3F/uOp76Hc0qsh++RcXknZj6Jdks2LZE2mGOBAgjsneMDi6y5/OROFyXWbOJCbwD5BFJOcu/Q0xFOvLk0IJ8giuFh9jXs52lujjIzF9Khe63v2Uekhk= ARC-Authentication-Results: i=1; vulcan.natalenko.name; auth=pass smtp.auth=oleksandr@natalenko.name smtp.mailfrom=oleksandr@natalenko.name Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi. 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. On another hand, the users of embedded devices, mentioned by Linus, should already know what scheduler to choose because dealing with embedded world assumes the person can decide this on their own, or with the help of abovementioned udev scripts and/or Documentation/ as a reference point. So I see no obstacles here, and the choice to rely on udev by default sounds reasonable. The question that remain is whether it is really important to mount a root partition while already using some specific scheduler? Why it cannot be done with "none", for instance? > So, probably 99% of Linux-kernel users will just stick to the default > I/O scheduler, mq-deadline, assuming that the algorithm by which that > scheduler was chosen was not "pick the scheduler with the longest > name", but "pick the best scheduler for most cases". The problem is > that, for single-queue devices with a speed below 400/500 KIOPS, the > default scheduler is apparently incomparably worse than bfq in terms > of responsiveness and latency for time-sensitive applications [2], and > in terms of throughput reached while controlling I/O [3]. And, in all > other tests ran so far, by any entity or group I'm aware of, bfq > results basically on par with or better than mq-deadline. And that's why major distributions are likely to default to BFQ via udev. No one argues with BFQ superiority here ☺. > So, I do understand your need for conservativeness, but, after so much > evidence on single-queue devices, and so many years! :), what's the > point in keeping Linux worse for virtually everybody, by default? From my point of view this is not a conservative approach at all. On contrary, offloading decisions to userspace aligns pretty well with recent trends like pressure metrics/userspace OOM killer, eBPF etc. The less unnecessary logic the kernel handles, the more flexibility it affords. -- Oleksandr Natalenko (post-factum) From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oleksandr Natalenko Subject: Re: [PATCH] block: BFQ default for single queue devices Date: Wed, 03 Oct 2018 13:49:25 +0200 Message-ID: <1eca41df95ff660eb247a3de666adeb4@natalenko.name> References: <20181002124329.21248-1-linus.walleij@linaro.org> <05fdbe23-ec01-895f-e67e-abff85c1ece2@kernel.dk> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-mtd" Errors-To: linux-mtd-bounces+gldm-linux-mtd-36=gmane.org@lists.infradead.org To: Paolo Valente Cc: Jens Axboe , Andreas Herrmann , Ulf Hansson , Jan Kara , Mel Gorman , Artem Bityutskiy , Richard Weinberger , Linus Walleij , linux-mmc , Adrian Hunter , Chunyan Zhang , linux-block , Mark Brown , linux-mtd@lists.infradead.org, Pavel Machek , 'Paolo Valente' via bfq-iosched , linux-kernel List-Id: linux-mmc@vger.kernel.org SGkuCgpPbiAwMy4xMC4yMDE4IDA4OjI5LCBQYW9sbyBWYWxlbnRlIHdyb3RlOgo+IEFzIGFsc28g TGludXMgVG9ydmFsZHMgY29tcGxhaW5lZCBbMV0sIHBlb3BsZSBmZWVsIGxvc3QgYW1vbmcKPiBJ L08tc2NoZWR1bGVyIG9wdGlvbnMuICBBY3R1YWwgZGlmZmVyZW5jZXMgYWNyb3NzIEkvTyBzY2hl ZHVsZXJzIGFyZQo+IGJhc2ljYWxseSBvYnNjdXJlIHRvIG5vbiBleHBlcnRzLiAgSW4gdGhpcyBy ZXNwZWN0LCBMaW51eC1rZXJuZWwKPiAndXNlcnMnIGFyZSB3YXkgbW9yZSB0aGFuIGEgZmV3IHRv cC1sZXZlbCBkaXN0cm9zIHRoYXQgY2FuIGFmZm9yZCBhCj4gc3Ryb25nIHBlcmZvcm1hbmNlIHRl YW0sIGFuZCB0aGF0LCBiYXNpbmcgb24gdGhlIGlucHV0IG9mIHN1Y2ggYSB0ZWFtLAo+IG1pZ2h0 IHZlbnR1cmUgbGlnaHQtaGVhcnRlZGx5IHRvIGNoYW5nZSBhIGNyaXRpY2FsIGNvbXBvbmVudCBs aWtlIGFuCj4gSS9PIHNjaGVkdWxlci4gIFBsdXMsIGFzIExpbnVzIFdhbGxlaWogcG9pbnRlZCBv dXQsIHNvbWUgdXNlcnMgc2ltcGx5Cj4gYXJlIG5vdCBkaXN0cm9zIHRoYXQgdXNlIHVkZXYuCgpJ IGZlZWwgYSBjb250cmFkaWN0aW9uIGluIHRoaXMgY291bnRlci1hcmd1bWVudC4gT24gb25lIGhh bmQsIHRoZXJlIGFyZSAKbG90cyBvZiwgbGV0J3MgY2FsbCB0aGVtLCBob21lIHVzZXJzLCB0aGF0 IHVzZSBtYWpvciBkaXN0cmlidXRpb25zIHdpdGggCnVkZXYsIHNvIHRoZSBkaXN0cmlidXRpb24g bWFpbnRhaW5lcnMgY2FuIHJlYXNvbmFibHkgZGVjaWRlIHdoaWNoIApzY2hlZHVsZXIgdG8gdXNl IGZvciB3aGljaCB0eXBlIG9mIGRldmljZSBiYXNlZCBvbiB0aGUgdWRldiBydWxlIGFuZCAKY29t bW9uIHNlbnNlIHByb3ZpZGVkIHZpYSBEb2N1bWVudGF0aW9uLyBieSBsaW51eC1ibG9jayBkZXZz LiBNb3Jlb3ZlciwgCm1vc3QgbGlrZWx5LCB0aG9zZSBydWxlcyBzaG91bGQgYmUgc2ltaWxhciBv ciB0aGUgc2FtZSBhY3Jvc3MgYWxsIHRoZSAKbWFqb3IgZGlzdHJvcyBhbmQgYXZhaWxhYmxlIHZp YSBzb21lIChzeXN0ZW1kPykgdXBzdHJlYW0uCgpPbiBhbm90aGVyIGhhbmQsIHRoZSB1c2VycyBv ZiBlbWJlZGRlZCBkZXZpY2VzLCBtZW50aW9uZWQgYnkgTGludXMsIApzaG91bGQgYWxyZWFkeSBr bm93IHdoYXQgc2NoZWR1bGVyIHRvIGNob29zZSBiZWNhdXNlIGRlYWxpbmcgd2l0aCAKZW1iZWRk ZWQgd29ybGQgYXNzdW1lcyB0aGUgcGVyc29uIGNhbiBkZWNpZGUgdGhpcyBvbiB0aGVpciBvd24s IG9yIHdpdGggCnRoZSBoZWxwIG9mIGFib3ZlbWVudGlvbmVkIHVkZXYgc2NyaXB0cyBhbmQvb3Ig RG9jdW1lbnRhdGlvbi8gYXMgYSAKcmVmZXJlbmNlIHBvaW50LgoKU28gSSBzZWUgbm8gb2JzdGFj bGVzIGhlcmUsIGFuZCB0aGUgY2hvaWNlIHRvIHJlbHkgb24gdWRldiBieSBkZWZhdWx0IApzb3Vu ZHMgcmVhc29uYWJsZS4KClRoZSBxdWVzdGlvbiB0aGF0IHJlbWFpbiBpcyB3aGV0aGVyIGl0IGlz IHJlYWxseSBpbXBvcnRhbnQgdG8gbW91bnQgYSAKcm9vdCBwYXJ0aXRpb24gd2hpbGUgYWxyZWFk eSB1c2luZyBzb21lIHNwZWNpZmljIHNjaGVkdWxlcj8gV2h5IGl0IApjYW5ub3QgYmUgZG9uZSB3 aXRoICJub25lIiwgZm9yIGluc3RhbmNlPwoKPiBTbywgcHJvYmFibHkgOTklIG9mIExpbnV4LWtl cm5lbCB1c2VycyB3aWxsIGp1c3Qgc3RpY2sgdG8gdGhlIGRlZmF1bHQKPiBJL08gc2NoZWR1bGVy LCBtcS1kZWFkbGluZSwgYXNzdW1pbmcgdGhhdCB0aGUgYWxnb3JpdGhtIGJ5IHdoaWNoIHRoYXQK PiBzY2hlZHVsZXIgd2FzIGNob3NlbiB3YXMgbm90ICJwaWNrIHRoZSBzY2hlZHVsZXIgd2l0aCB0 aGUgbG9uZ2VzdAo+IG5hbWUiLCBidXQgInBpY2sgdGhlIGJlc3Qgc2NoZWR1bGVyIGZvciBtb3N0 IGNhc2VzIi4gIFRoZSBwcm9ibGVtIGlzCj4gdGhhdCwgZm9yIHNpbmdsZS1xdWV1ZSBkZXZpY2Vz IHdpdGggYSBzcGVlZCBiZWxvdyA0MDAvNTAwIEtJT1BTLCB0aGUKPiBkZWZhdWx0IHNjaGVkdWxl ciBpcyBhcHBhcmVudGx5IGluY29tcGFyYWJseSB3b3JzZSB0aGFuIGJmcSBpbiB0ZXJtcwo+IG9m IHJlc3BvbnNpdmVuZXNzIGFuZCBsYXRlbmN5IGZvciB0aW1lLXNlbnNpdGl2ZSBhcHBsaWNhdGlv bnMgWzJdLCBhbmQKPiBpbiB0ZXJtcyBvZiB0aHJvdWdocHV0IHJlYWNoZWQgd2hpbGUgY29udHJv bGxpbmcgSS9PIFszXS4gIEFuZCwgaW4gYWxsCj4gb3RoZXIgdGVzdHMgcmFuIHNvIGZhciwgYnkg YW55IGVudGl0eSBvciBncm91cCBJJ20gYXdhcmUgb2YsIGJmcQo+IHJlc3VsdHMgYmFzaWNhbGx5 IG9uIHBhciB3aXRoIG9yIGJldHRlciB0aGFuIG1xLWRlYWRsaW5lLgoKQW5kIHRoYXQncyB3aHkg bWFqb3IgZGlzdHJpYnV0aW9ucyBhcmUgbGlrZWx5IHRvIGRlZmF1bHQgdG8gQkZRIHZpYSAKdWRl di4gTm8gb25lIGFyZ3VlcyB3aXRoIEJGUSBzdXBlcmlvcml0eSBoZXJlIOKYui4KCj4gU28sIEkg ZG8gdW5kZXJzdGFuZCB5b3VyIG5lZWQgZm9yIGNvbnNlcnZhdGl2ZW5lc3MsIGJ1dCwgYWZ0ZXIg c28gbXVjaAo+IGV2aWRlbmNlIG9uIHNpbmdsZS1xdWV1ZSBkZXZpY2VzLCBhbmQgc28gbWFueSB5 ZWFycyEgOiksIHdoYXQncyB0aGUKPiBwb2ludCBpbiBrZWVwaW5nIExpbnV4IHdvcnNlIGZvciB2 aXJ0dWFsbHkgZXZlcnlib2R5LCBieSBkZWZhdWx0PwoKIEZyb20gbXkgcG9pbnQgb2YgdmlldyB0 aGlzIGlzIG5vdCBhIGNvbnNlcnZhdGl2ZSBhcHByb2FjaCBhdCBhbGwuIE9uIApjb250cmFyeSwg b2ZmbG9hZGluZyBkZWNpc2lvbnMgdG8gdXNlcnNwYWNlIGFsaWducyBwcmV0dHkgd2VsbCB3aXRo IApyZWNlbnQgdHJlbmRzIGxpa2UgcHJlc3N1cmUgbWV0cmljcy91c2Vyc3BhY2UgT09NIGtpbGxl ciwgZUJQRiBldGMuIFRoZSAKbGVzcyB1bm5lY2Vzc2FyeSBsb2dpYyB0aGUga2VybmVsIGhhbmRs ZXMsIHRoZSBtb3JlIGZsZXhpYmlsaXR5IGl0IAphZmZvcmRzLgoKLS0gCiAgIE9sZWtzYW5kciBO YXRhbGVua28gKHBvc3QtZmFjdHVtKQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCkxpbnV4IE1URCBkaXNjdXNzaW9uIG1haWxpbmcgbGlzdApo dHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LW10ZC8K