From patchwork Thu May 31 14:45:05 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 10441247 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id CB969602BC for ; Thu, 31 May 2018 14:45:36 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B75E02973B for ; Thu, 31 May 2018 14:45:36 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id ABC4529740; Thu, 31 May 2018 14:45:36 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 100C92973B for ; Thu, 31 May 2018 14:45:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755445AbeEaOpe (ORCPT ); Thu, 31 May 2018 10:45:34 -0400 Received: from mail-wr0-f196.google.com ([209.85.128.196]:45448 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755163AbeEaOpa (ORCPT ); Thu, 31 May 2018 10:45:30 -0400 Received: by mail-wr0-f196.google.com with SMTP id o12-v6so2218065wrm.12 for ; Thu, 31 May 2018 07:45:29 -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=IFrDgLL2djABtcZVT/83HhEbvNP72Hw1DrJc+3k+XAk=; b=YQdbOh2PNAjed89u+zit1vsprYVGY8gVgSWIjoxLRX2b5ZMBEUMzELtelBDbrRZC56 qBer9F3YY30gyD6r+xy81P+4qax+s1M9AVoHZ4q9l515xbsdcfoq7Tc13utK56OtLIQ0 Z4WmszDBdEna4fpHUUsT35Rm2+z6IZhZbuIIU= 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=IFrDgLL2djABtcZVT/83HhEbvNP72Hw1DrJc+3k+XAk=; b=Wv5w0ePQ6idTwadaGbAmFlDFinUkCU8izW2REUrnpPgJzQ4B2XzwoyZxLcynmCfygV 0DREkIE172DJvNR4ImImstgFLGls9Ki2qL7V8Ea0uQ4bIUGhWAbkFAJgcy5+Ow35u+A8 eEmBFuc4VqDYh6uPZHFimJzqScANnyAcMO4lMMLtOEf2tobEsqPq/HPfpv6NrflSTz4/ 2K6/Hfi9+tdRZV2rqgigrMhYa82cemrIy+fi3O0awig5t9dxJmNZyW86H38YipoRngvk eR2PSrfFgyvO8h4JzuRgm43NmV9Ue7A6Pyi2Cr0QA6MOFzZ0BBa2AKBEeJJmx87OiWvX VzPg== X-Gm-Message-State: ALKqPwexRhpxrqx54c4EuIK4eF/cIlCQ2Qh9r+52iZ0vY9o9c0oWb4AB Et4hkbQ7eGL9Jpf3cKzr+OCN7w== X-Google-Smtp-Source: ADUXVKKTuk/x387Qoht06FeYPoXa2cJ7X8CS5TY0yPCPkkIsEf7k5Om0Vguu/GbsssO9h4wMQNk85w== X-Received: by 2002:adf:a54a:: with SMTP id j10-v6mr6243312wrb.155.1527777928757; Thu, 31 May 2018 07:45:28 -0700 (PDT) Received: from localhost.localdomain (146-241-12-84.dyn.eolo.it. [146.241.12.84]) by smtp.gmail.com with ESMTPSA id y45-v6sm36106869wrd.97.2018.05.31.07.45.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 May 2018 07:45:27 -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, linus.walleij@linaro.org, bfq-iosched@googlegroups.com, oleksandr@natalenko.name, sapienza.dav@gmail.com, 177992@studenti.unimore.it, Paolo Valente Subject: [PATCH BUGFIX/IMPROVEMENTS 1/4] block, bfq: add description of weight-raising heuristics Date: Thu, 31 May 2018 16:45:05 +0200 Message-Id: <20180531144508.3927-2-paolo.valente@linaro.org> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180531144508.3927-1-paolo.valente@linaro.org> References: <20180531144508.3927-1-paolo.valente@linaro.org> Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP A description of how weight raising works is missing in BFQ sources. In addition, the code for handling weight raising is scattered across a few functions. This makes it rather hard to understand the mechanism and its rationale. This commits adds such a description at the beginning of the main source file. Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 80 +++++++++++++++++++++++++++++++++++++---------------- 1 file changed, 56 insertions(+), 24 deletions(-) diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index f71a5846b629..f3703e7431aa 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -49,9 +49,39 @@ * * In particular, to provide these low-latency guarantees, BFQ * explicitly privileges the I/O of two classes of time-sensitive - * applications: interactive and soft real-time. This feature enables - * BFQ to provide applications in these classes with a very low - * latency. Finally, BFQ also features additional heuristics for + * applications: interactive and soft real-time. In more detail, BFQ + * behaves this way if the low_latency parameter is set (default + * configuration). This feature enables BFQ to provide applications in + * these classes with a very low latency. + * + * To implement this feature, BFQ constantly tries to detect whether + * the I/O requests in a bfq_queue come from an interactive or a soft + * real-time application. For brevity, in these cases, the queue is + * said to be interactive or soft real-time. In both cases, BFQ + * privileges the service of the queue, over that of non-interactive + * and non-soft-real-time queues. This privileging is performed, + * mainly, by raising the weight of the queue. So, for brevity, we + * call just weight-raising periods the time periods during which a + * queue is privileged, because deemed interactive or soft real-time. + * + * The detection of soft real-time queues/applications is described in + * detail in the comments on the function + * bfq_bfqq_softrt_next_start. On the other hand, the detection of an + * interactive queue works as follows: a queue is deemed interactive + * if it is constantly non empty only for a limited time interval, + * after which it does become empty. The queue may be deemed + * interactive again (for a limited time), if it restarts being + * constantly non empty, provided that this happens only after the + * queue has remained empty for a given minimum idle time. + * + * By default, BFQ computes automatically the above maximum time + * interval, i.e., the time interval after which a constantly + * non-empty queue stops being deemed interactive. Since a queue is + * weight-raised while it is deemed interactive, this maximum time + * interval happens to coincide with the (maximum) duration of the + * weight-raising for interactive queues. + * + * Finally, BFQ also features additional heuristics for * preserving both a low latency and a high throughput on NCQ-capable, * rotational or flash-based devices, and to get the job done quickly * for applications consisting in many I/O-bound processes. @@ -61,14 +91,14 @@ * 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 - * formulas of the guarantees and formal proofs of all the properties. - * With respect to the version of BFQ presented in these papers, this - * implementation adds a few more heuristics, such as the one that - * guarantees a low latency to soft real-time applications, and a - * hierarchical extension based on H-WF2Q+. + * 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 formulas of the guarantees and formal proofs of all the + * properties. With respect to the version of BFQ presented in these + * papers, this implementation adds a few more heuristics, such as the + * ones that guarantee a low latency to interactive and soft real-time + * applications, and a hierarchical extension based on H-WF2Q+. * * B-WF2Q+ is based on WF2Q+, which is described in [2], together with * H-WF2Q+, while the augmented tree used here to implement B-WF2Q+ @@ -218,21 +248,23 @@ static struct kmem_cache *bfq_pool; #define BFQ_RATE_SHIFT 16 /* - * By default, BFQ computes the duration of the weight raising for - * interactive applications automatically, using the following formula: - * duration = (R / r) * T, where r is the peak rate of the device, and - * R and T are two reference parameters. - * In particular, R is the peak rate of the reference device (see - * below), and T is a reference time: given the systems that are - * likely to be installed on the reference device according to its - * speed class, T is about the maximum time needed, under BFQ and + * When configured for computing the duration of the weight-raising + * for interactive queues automatically (see the comments at the + * beginning of this file), BFQ does it using the following formula: + * duration = (R / r) * T, + * where r is the peak rate of the device, and R + * and T are two reference parameters. In particular, + * R is the peak rate of the reference device (see below), and + * T is a reference time: given the systems that are likely + * to be installed on the reference device according to its speed + * class, T is about the maximum time needed, under BFQ and * while reading two files in parallel, to load typical large * applications on these systems (see the comments on - * max_service_from_wr below, for more details on how T is obtained). - * In practice, the slower/faster the device at hand is, the more/less - * it takes to load applications with respect to the reference device. - * Accordingly, the longer/shorter BFQ grants weight raising to - * interactive applications. + * max_service_from_wr below, for more details on how T is + * obtained). In practice, the slower/faster the device at hand is, + * the more/less it takes to load applications with respect to the + * reference device. Accordingly, the longer/shorter BFQ grants + * weight raising to interactive applications. * * BFQ uses four different reference pairs (R, T), depending on: * . whether the device is rotational or non-rotational;