From patchwork Thu Aug 31 18:00:30 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 111416 Delivered-To: patch@linaro.org Received: by 10.140.95.112 with SMTP id h103csp2923160qge; Thu, 31 Aug 2017 11:01:08 -0700 (PDT) X-Received: by 10.84.224.10 with SMTP id r10mr3474082plj.149.1504202468498; Thu, 31 Aug 2017 11:01:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1504202468; cv=none; d=google.com; s=arc-20160816; b=FMnTsqD26fdLAKetb7LlFN5xFi1LUR/KoySwvbvsdlKaYkI0tO92yKN+J0coL0YZSu +p/1y0LunfhRCEiStP8pCtNldlOEiRN/kRCuQN/uiF2Uo+xPiqLRVAx3J/34rJy6EQFR pMQtsnmVx+fA+tSjdqQfmitnp0s3ollEv5v1gA/lIZOXkIloWH32pKqfJFDY2CpyPjSj lXvg8HLgnVlpwJVDkAUSo19mB1WtyQ65lwvDkg3xJBGElaXCONZFQQM2ZQoNPUU29xdJ CIisZDYNAxaZ2sVhgb0+uVoUiQbs5BI2BRgj/kapTsP3Pydd7L9mmNqXrXg4zw/iM2Zt C/Nw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=lVpjr/BtMpHWSYXoqaV+PV14vAri+09rIWDDPipEXJU=; b=DQS97kovpog+uqIuUgM9Zzz1chKyE6pcMuhiGnbLd+yRb37fCd+wHkurpGWPKCCggH CtLQ9dOu5az8o0YDFVAkxoVKXg4Z4piCNH+PFk/Feoe+zSQSJw3/Z4AL7iSUE1riJArS XJIw7ZetUOTd/bonWVe5nW270HKuCczszzn2JU4+WK3tPkjkdDqOtCvobiUyPYJWBsAX K7OmcxlvmQn2poYKFMTFVp3gCtblscvb2qj8ay2rzeDgTSOzoF2UJthLkTT8psWdVxc2 IH9grQmxb9j8qUUS7GSv7T+h5OQohHwTCYCe3d3VLdIaKo6OhoGHCPimdPAmP1gCvei1 X09g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=X1txdeY0; 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 d6si188826pfh.479.2017.08.31.11.01.08; Thu, 31 Aug 2017 11:01:08 -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 header.s=google header.b=X1txdeY0; 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 S1751463AbdHaSBE (ORCPT + 26 others); Thu, 31 Aug 2017 14:01:04 -0400 Received: from mail-wm0-f53.google.com ([74.125.82.53]:38137 "EHLO mail-wm0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751074AbdHaSBB (ORCPT ); Thu, 31 Aug 2017 14:01:01 -0400 Received: by mail-wm0-f53.google.com with SMTP id 187so2266243wmn.1 for ; Thu, 31 Aug 2017 11:01:00 -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:in-reply-to:references; bh=lVpjr/BtMpHWSYXoqaV+PV14vAri+09rIWDDPipEXJU=; b=X1txdeY0Y0Y8MbnSdG8m/MOcZbFir8FrOLIE9/snHJktBMmgN1Wl1msMR/JowzTpbh 9VERz4k8tHJak9qgDqlWQmhDcel4VlOVoBkk3zbBahHfwmTcbNCfGfSR2A+xz++Yv38X SVQjdHj1k4OsxqBVuiMvfGu0HPGqIfiXRa0w4= 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:in-reply-to :references; bh=lVpjr/BtMpHWSYXoqaV+PV14vAri+09rIWDDPipEXJU=; b=JpGWjCh89WP9RHbFz5q4x6dyz9QjvZnLEYOcaC6oZRKOSsDhgqJmgvv3gIh0y4qA8c V9Iy9p/geDBo9oJ+VmBdwX5i7MaZy6yMAR7faZixyQr0wXv/baxMu2TJTunRHRQhB0xc hfBdEXzbyjhz6m3wJ1sGfO18zhkKQLje6f7mdjGe4dqSFMqIvvyLAHDJ0R2vq0RzINLP rLjW6+CEljJaVvTcaZlo4Mx+8Yw3PHvMStnNG4IQ+Zkm8ET9yOG7h0EmCdXpy5TXQeFl pgcIXVJlwUGHLOrmIbBufdfX3rEmiLQREeUv7qns9WfZh7wqGJVW4WfRVFvZdtpVWtHd U2Ow== X-Gm-Message-State: AHPjjUjxQ0upBt4C1O+LTlj73k445e7iX/XZ2DjOgGCUkhdGoj6j4MO3 43ldyVm0VrpfvXSV X-Google-Smtp-Source: ADKCNb4WHcZFGe2vYEt1pQZYWVvqj+s0QYi9ZtSaL8JufcZuWUUWCs15EEJztxy2o7gF3QgHS1R57Q== X-Received: by 10.28.12.11 with SMTP id 11mr1185068wmm.180.1504202460062; Thu, 31 Aug 2017 11:01:00 -0700 (PDT) Received: from localhost.localdomain ([185.14.8.94]) by smtp.gmail.com with ESMTPSA id 66sm635285wmn.17.2017.08.31.11.00.57 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 31 Aug 2017 11:00:58 -0700 (PDT) From: Paolo Valente To: Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, ulf.hansson@linaro.org, broonie@kernel.org, jeremywh7@gmail.com, lnicola@dend.ro, Paolo Valente Subject: [PATCH BUGFIX/IMPROVEMENT 1/2] doc, block, bfq: fix some typos and remove stale stuff Date: Thu, 31 Aug 2017 20:00:30 +0200 Message-Id: <20170831180031.3747-2-paolo.valente@linaro.org> X-Mailer: git-send-email 2.10.0 In-Reply-To: <20170831180031.3747-1-paolo.valente@linaro.org> References: <20170831180031.3747-1-paolo.valente@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In addition to containing some typos and stale sentences, the file bfq-iosched.txt still mentioned a set of sysfs parameters that have been removed from this version of bfq. This commit fixes all these issues. Signed-off-by: Paolo Valente Reviewed-by: Jeremy Hickman Reviewed-by: Laurentiu Nicola --- Documentation/block/bfq-iosched.txt | 66 ++++++------------------------------- 1 file changed, 10 insertions(+), 56 deletions(-) -- 2.10.0 diff --git a/Documentation/block/bfq-iosched.txt b/Documentation/block/bfq-iosched.txt index 05e2822..03ff4cc 100644 --- a/Documentation/block/bfq-iosched.txt +++ b/Documentation/block/bfq-iosched.txt @@ -16,14 +16,16 @@ 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. +for that device, by setting low_latency to 0. See Section 3 for +details on how to configure BFQ for the desired tradeoff between +latency and throughput, or on how to maximize throughput. 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 sequential I/O (e.g., 8-12 GB/s if I/O requests are 256 KB large), and -to 120-200 MB/s with 4KB random I/O. BFQ has not yet been tested on -multi-queue devices. +to 120-200 MB/s with 4KB random I/O. BFQ is currently being tested on +multi-queue devices too. The table of contents follow. Impatients can just jump to Section 3. @@ -154,10 +156,10 @@ plus a lot of code, are borrowed from CFQ. - With respect to idling for service guarantees, if several processes are competing for the device at the same time, but - all processes (and groups, after the following commit) have - the same weight, then BFQ guarantees the expected throughput - distribution without ever idling the device. Throughput is - thus as high as possible in this common scenario. + all processes and groups have the same weight, then BFQ + guarantees the expected throughput distribution without ever + idling the device. Throughput is thus as high as possible in + this common scenario. - If low-latency mode is enabled (default configuration), BFQ executes some special heuristics to detect interactive and soft @@ -191,10 +193,7 @@ plus a lot of code, are borrowed from CFQ. - Queues are scheduled according to a variant of WF2Q+, named B-WF2Q+, and implemented using an augmented rb-tree to preserve an O(log N) overall complexity. See [2] for more details. B-WF2Q+ is - also ready for hierarchical scheduling. However, for a cleaner - logical breakdown, the code that enables and completes - hierarchical support is provided in the next commit, which focuses - exactly on this feature. + also ready for hierarchical scheduling, details in Section 4. - B-WF2Q+ guarantees a tight deviation with respect to an ideal, perfectly fair, and smooth service. In particular, B-WF2Q+ @@ -427,51 +426,6 @@ Read-only parameter, used to show the weights of the currently active BFQ queues. -wr_ tunables ------------- - -BFQ exports a few parameters to control/tune the behavior of -low-latency heuristics. - -wr_coeff - -Factor by which the weight of a weight-raised queue is multiplied. If -the queue is deemed soft real-time, then the weight is further -multiplied by an additional, constant factor. - -wr_max_time - -Maximum duration of a weight-raising period for an interactive task -(ms). If set to zero (default value), then this value is computed -automatically, as a function of the peak rate of the device. In any -case, when the value of this parameter is read, it always reports the -current duration, regardless of whether it has been set manually or -computed automatically. - -wr_max_softrt_rate - -Maximum service rate below which a queue is deemed to be associated -with a soft real-time application, and is then weight-raised -accordingly (sectors/sec). - -wr_min_idle_time - -Minimum idle period after which interactive weight-raising may be -reactivated for a queue (in ms). - -wr_rt_max_time - -Maximum weight-raising duration for soft real-time queues (in ms). The -start time from which this duration is considered is automatically -moved forward if the queue is detected to be still soft real-time -before the current soft real-time weight-raising period finishes. - -wr_min_inter_arr_async - -Minimum period between I/O request arrivals after which weight-raising -may be reactivated for an already busy async queue (in ms). - - 4. Group scheduling with BFQ ============================