From patchwork Tue May 9 10:54:23 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 98903 Delivered-To: patch@linaro.org Received: by 10.140.96.100 with SMTP id j91csp1756343qge; Tue, 9 May 2017 03:54:55 -0700 (PDT) X-Received: by 10.84.197.3 with SMTP id m3mr92252783pld.3.1494327295173; Tue, 09 May 2017 03:54:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1494327295; cv=none; d=google.com; s=arc-20160816; b=RqCW8mO/BsTn6Fa3/3sId3kkqxsZULQVhQ7sNl42izFrULQohMo8WZn/OfAfV14jC6 wFXd05HiChQK6vVUmwEkdseb7Y0inaUsBKPpRWC2tfz8toLAauaZPG9mkwxqKGfmDK7T Ex3lQ1LwirmHC4Cqwddfd4Tp2lUdmWqyyYXIro9QwmELsGEgRjFKMLRrgntCcyIJLrXC 9/HCnv404Rt2BmYjDwS2wypfjyc5h5cikrgJ6ApiFr3KgXMlsOBoxTIdZ7lCHzd6Vjc+ xZaQ97R4sxHwE2Iahripnho8HmRJ/e4fOlr06u7dSIpMmcCxjj7Cty190Bs1fV8p0yzJ QW4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=nMVLgKzaSU7d2pXv2jRKyD2R6dwQsguUxV4o6HZfSHo=; b=rt5yrA83Ec3zl7OnweV3j2daeETGy8v7aDYuWQWoWUSVm0reT6syiN7BrwkMobZmQ8 YqMyTfdDIasYR/8Hfr1Kf0wRfp0B0Lt30TkMdhJrgGj/DUGsnziTNWrfubXP7mXqaiF0 7XpuHI+s7yGzjeDSiiHYO1zzTjErf03HcLFnN+1QSlo2yX97ZZ7p897Gk2diue8wBfAJ Pj7EpGgsc1YFkH6TDG7WbWruwxDXCaIKX12UJU3fK9w5vIUqopeWlMUrUszm7Icdj6eV zIAXMauiRpfbi76+mVCtRQ2Zf6Fpzzf1xmCiMXdUEm4coup6nHUmFjWM1b/yDSFmWufR j4lg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q2si12742152pgc.397.2017.05.09.03.54.54; Tue, 09 May 2017 03:54:55 -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; dkim=pass header.i=@linaro.org; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752654AbdEIKyg (ORCPT + 25 others); Tue, 9 May 2017 06:54:36 -0400 Received: from mail-wr0-f169.google.com ([209.85.128.169]:34582 "EHLO mail-wr0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751295AbdEIKye (ORCPT ); Tue, 9 May 2017 06:54:34 -0400 Received: by mail-wr0-f169.google.com with SMTP id l9so67238689wre.1 for ; Tue, 09 May 2017 03:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=nMVLgKzaSU7d2pXv2jRKyD2R6dwQsguUxV4o6HZfSHo=; b=IN8eobxm2w48idcnsioz+Jw4vgFyY/+PFnFqKIZX/C+vDOgvwFaY0QuHaCZiLYvOFI REwHci/eYN9BrzRcnLK9vj3xO6qTlpgbWlDojHScWiUuYV62Azx31mLDOoDAJCqoHmZ3 bdEOt/L4uVZqG8t8jHrOic4k7C43yctTpYxHM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=nMVLgKzaSU7d2pXv2jRKyD2R6dwQsguUxV4o6HZfSHo=; b=LI5GfCjQEpLSFfxGEX7zswSG+pKIkPtBrHGqQyJ9/B9T5aGb/gWk0sGt7jdWBzbo7b lwv9BWCa6S/IoFXb3SQ/ICVV9Ix/O7hpW+4wmTR4EIneo/TKY4NJjJwPxn521DUBrPiH 4yk9JGeYVMd8IiFu6JhYP97FfDOEQW+WSk6orunoOFJSPs9mn6ROiShYeOYPf2YVsdAM GU3a4of4klrT//CbOKMEtiuF9n1bFlVR1gUsXHQaUXxb09/6gEjYfG6wqJVmkY762Wft hUAYT14LIQHIPcMTXEdmFRveM2BrkXrOklXkahHRgSRBIfKMbqZCezXARudQv1SSJMYE JWGQ== X-Gm-Message-State: AN3rC/5vQxcLZn6pwFhEGrlmcDdAYF8iqvDCGMqNyUU0RP784i5xQn24 0lcRRwlhHiBmrF7V X-Received: by 10.223.130.168 with SMTP id 37mr44676080wrc.16.1494327273058; Tue, 09 May 2017 03:54:33 -0700 (PDT) Received: from localhost.localdomain ([185.14.11.197]) by smtp.gmail.com with ESMTPSA id o97sm18350157wrc.48.2017.05.09.03.54.31 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 09 May 2017 03:54:32 -0700 (PDT) From: Paolo Valente To: Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, ulf.hansson@linaro.org, linus.walleij@linaro.org, broonie@kernel.org, Paolo Valente Subject: [PATCH BUGFIX] block, bfq: stress that low_latency must be off to get max throughput Date: Tue, 9 May 2017 12:54:23 +0200 Message-Id: <20170509105423.3672-1-paolo.valente@linaro.org> X-Mailer: git-send-email 2.10.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The introduction of the BFQ and Kyber I/O schedulers has triggered a new wave of I/O benchmarks. Unfortunately, comments and discussions on these benchmarks confirm that there is still little awareness that it is very hard to achieve, at the same time, a low latency and a high throughput. In particular, virtually all benchmarks measure throughput, or throughput-related figures of merit, but, for BFQ, they use the scheduler in its default configuration. This configuration is geared, instead, toward a low latency. This is evidently a sign that BFQ documentation is still too unclear on this important aspect. This commit addresses this issue by stressing how BFQ configuration must be (easily) changed if the only goal is maximum throughput. Signed-off-by: Paolo Valente --- Documentation/block/bfq-iosched.txt | 17 ++++++++++++++++- block/bfq-iosched.c | 5 +++++ 2 files changed, 21 insertions(+), 1 deletion(-) -- 2.10.0 diff --git a/Documentation/block/bfq-iosched.txt b/Documentation/block/bfq-iosched.txt index 1b87df6..05e2822 100644 --- a/Documentation/block/bfq-iosched.txt +++ b/Documentation/block/bfq-iosched.txt @@ -11,6 +11,13 @@ controllers), BFQ's main features are: groups (switching back to time distribution when needed to keep throughput high). +In its default configuration, BFQ privileges latency over +throughput. So, when needed for achieving a lower latency, BFQ builds +schedules that may lead to a lower throughput. If your main or only +goal, for a given device, is to achieve the maximum-possible +throughput at all times, then do switch off all low-latency heuristics +for that device, by setting low_latency to 0. Full details in Section 3. + On average CPUs, the current version of BFQ can handle devices performing at most ~30K IOPS; at most ~50 KIOPS on faster CPUs. As a reference, 30-50 KIOPS correspond to very high bandwidths with @@ -375,11 +382,19 @@ default, low latency mode is enabled. If enabled, interactive and soft real-time applications are privileged and experience a lower latency, as explained in more detail in the description of how BFQ works. -DO NOT enable this mode if you need full control on bandwidth +DISABLE this mode if you need full control on bandwidth distribution. In fact, if it is enabled, then BFQ automatically increases the bandwidth share of privileged applications, as the main means to guarantee a lower latency to them. +In addition, as already highlighted at the beginning of this document, +DISABLE this mode if your only goal is to achieve a high throughput. +In fact, privileging the I/O of some application over the rest may +entail a lower throughput. To achieve the highest-possible throughput +on a non-rotational device, setting slice_idle to 0 may be needed too +(at the cost of giving up any strong guarantee on fairness and low +latency). + timeout_sync ------------ diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index bd8499e..08ce450 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -56,6 +56,11 @@ * rotational or flash-based devices, and to get the job done quickly * for applications consisting in many I/O-bound processes. * + * NOTE: if the main or only goal, with a given device, is to achieve + * the maximum-possible throughput at all times, then do switch off + * all low-latency heuristics for that device, by setting low_latency + * to 0. + * * BFQ is described in [1], where also a reference to the initial, more * theoretical paper on BFQ can be found. The interested reader can find * in the latter paper full details on the main algorithm, as well as