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: 137417 Delivered-To: patch@linaro.org Received: by 2002:a2e:9706:0:0:0:0:0 with SMTP id r6-v6csp6691338lji; Thu, 31 May 2018 07:45:39 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIJFHp958Sd6ktiyw7JmyEOLLFU1qQbAgyceJASSFcnWYGic9x2bx+WmJXXrGlyaeLB6v5z X-Received: by 2002:a17:902:422:: with SMTP id 31-v6mr7466022ple.320.1527777939136; Thu, 31 May 2018 07:45:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527777939; cv=none; d=google.com; s=arc-20160816; b=YrunI7jZz54sY+t6w64IqbZlaI765seCbZlSydGLdh4cSgbRtEiailjVCt93AiikB/ h8uXumnE18u/HzVQS8LiUctAPYvATCkoeuvMA6vvdmD5bl7mK5E+9Jt6sfZWnCbWbnfN 6l+kfUFNlGu54DaBE5d7ab9n/KHYSmsjr+0eih5Gwvtzt4rD5EFgno6lMOve7kvaTx04 kKo4G7euEW5wkW6H4omWUIpiIrfZor+lv+vEFQ1yE4n25+PjF9CTFEBGyh5dPs6C6JHL EIi0S5fyW3RmO0CA5fUzeCYF3fEAae7Rg8Lgq1JsLyYbPWjmCqOFbH1dpGRjfimJekO+ y/2g== 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=IFrDgLL2djABtcZVT/83HhEbvNP72Hw1DrJc+3k+XAk=; b=Ascdo7rxqOyzzFgttNxLybOgEp6zigd2Pr49BMWdKhvxrBjKAUG3Vmta22vqgSlaXQ avKyzSoNK0Dg5UqpMS9HRJJZRxV85STAVMmKDr4OCJBPN7hcBmFJf5bE0xjo/ZShW1tH DKFhjjuiUU3JgFmTMpwUak0UF5iPdIYtxAei6Nyx9MXB4zZU3QU5UAXUtu58aYRZ+zl8 5+ADyRi3sW5rlLWXVUK7OAWp84uPPNEWzV815gJRp49wjGi+J8iW/gB0edJ5aO/SJJk8 SKNJv+zI7j9zE8m/cIFoLywfWAf4QvJVZrwueBIpFbkAAAVhqnG0brwWeOS5f0N0FIVk Oe6A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=YQdbOh2P; 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 v8-v6si37009656plo.306.2018.05.31.07.45.38; Thu, 31 May 2018 07:45:39 -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=YQdbOh2P; 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 S1755463AbeEaOpg (ORCPT + 30 others); Thu, 31 May 2018 10:45:36 -0400 Received: from mail-wr0-f195.google.com ([209.85.128.195]:40474 "EHLO mail-wr0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755117AbeEaOpa (ORCPT ); Thu, 31 May 2018 10:45:30 -0400 Received: by mail-wr0-f195.google.com with SMTP id l41-v6so33329136wre.7 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=NC8NuP3ElXXti0gcK+DVFd8Kl3SjgjbtOYrI0DxgDBn8Ca1UuJpYgUZrdldAs3b6hy +TrW7ltN5jaCe0sBPIXwhLFl2prpWOIcokHOYf49ZhAxQI3r/eoGYUIWgMIIlzh7IfgS s0L4kzRYHM/Keyvg3IEcGyZTFX3dkO08G4SKaG6b/2PCrHw91yhzMKVVkSSDSn9tHtcM zasGCOA0iUeZDq+pgGHX2Y5J0koxv5SGWARDn9KBf5Sfd02ov4YxXpjtJGb+QjnvqA7Q AR4KynfbIHadvYh2m0RGRb59JDlme02kVk3IsDXBmhTX9Wk7xp/1w5ciZzgrRED9g/pR HtAQ== X-Gm-Message-State: ALKqPwel1oCc1QbeJqPL6KYBTV0UmB8c1hPIRlJQf8gPPq8UNu+CE9i1 UrobKc7S7NmLjTwDO8OIpEsaMQ== 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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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(-) -- 2.16.1 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; From patchwork Thu May 31 14:45:06 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 137420 Delivered-To: patch@linaro.org Received: by 2002:a2e:9706:0:0:0:0:0 with SMTP id r6-v6csp6692014lji; Thu, 31 May 2018 07:46:10 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJEiLIqrIDHDPg2EVqnGiYBRFBE9+rHBbpl03x/Q6mdVKVXxf3RbOgsrFrfbDuUVpO7R5S6 X-Received: by 2002:a17:902:1a8:: with SMTP id b37-v6mr7475251plb.326.1527777970140; Thu, 31 May 2018 07:46:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527777970; cv=none; d=google.com; s=arc-20160816; b=aU3qsMgmfBmJ0PmYzgQ9cttsVs3Lti3Zg76ObSbfu9HgqdzV1arkESP7qCAZf/4QSk rz6rXK/AWbHx13py9i3quRlOHydGzzuA6/QDMoNtJTKxxBaMYtBb6RY/loG/UYj8tOKc cMi/sVphkOpdCBQpg9hgckupI+yR0udxRTclxNlpJqub8MjQYGmA//T6goWrkmJO0+/M kIdU3miYBuSOQJN6K5E1iWcO3tmuSps/5b5AqWUBUUw8wSv9WYIBgnpzRwPr6pI7oaaD FCfAYgkE58Xj/Xo3YpKEX/uyjtNsJE99c2cAuuoRmSCXxf944199tGRj4n5hh0cv2l7A OF5g== 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=sgT80lJDZuXrK3Hc6RP6kg3Wz7JpN74EdKgIT7FqXKk=; b=VVBfvNRNkvgedH7R0WWtN67UQJuQCtJe6RRtv9NTpZo2jiHUB4iyZbbtLEd55+yaan yYmdGLl4xd9aErhHTVXiPhnz/Cu1p4zMhTdYcfWwujEJMYY9cEDV2Fpu4RkdB28MOvZ8 UaYPJtgQ0wt6+tnI9axseG9yoCv+JtJAQzf6NMpRiefTAifwsaXy12myLPqrnQwDsFFp sOrTFOtp0i58JdXP8yvKCW6eoJ2Ul0ALjrHyqPPhCMcua0PHHINgp5vVZy0OeB/NCuzH +MCO7zNeYePZw5KIZZ0PcMcvskDsKsoEfGs6oyLcaZr26VilCpO8jTIYViQXVihTAn69 qg/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=acjpMXmn; 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 p91-v6si37495154plb.457.2018.05.31.07.46.09; Thu, 31 May 2018 07:46:10 -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=acjpMXmn; 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 S1755502AbeEaOqI (ORCPT + 30 others); Thu, 31 May 2018 10:46:08 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:35229 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755437AbeEaOpb (ORCPT ); Thu, 31 May 2018 10:45:31 -0400 Received: by mail-wr0-f193.google.com with SMTP id i14-v6so33275032wre.2 for ; Thu, 31 May 2018 07:45:31 -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=sgT80lJDZuXrK3Hc6RP6kg3Wz7JpN74EdKgIT7FqXKk=; b=acjpMXmn/fD3qV4XI9Pc9WKQWJUrTmFAprlauhugMyAgcpm/XYUY70Smb7jjktU0g0 0xugg4/Z8Y7MgQqTjzaJaDQ0mH49PxbaygVyMpVv+3BChD8d/NHB5eWqjvdXrJ/cVBzz cS2u6dOU1a76nxR623BZr9lBQmv3jv3nC+4zw= 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=sgT80lJDZuXrK3Hc6RP6kg3Wz7JpN74EdKgIT7FqXKk=; b=lGN/9BOHl9/LOPj0Uub2hnj5sFS80lUhviM14kCIaAImPxT6x7sIg6hSP3H2xniRmd QINluIRJEtHPwZqhO6Y9ymIxodaWWYPwd1DwMCHYvcBJ33OXs1CRxg10to6kieVXLSq+ cQck9MDviJdIUxxNbxC+If4DkmE4NK3PxjsVlNaKLXElId2YkBM/v+E+5q8WrFwcY8Lz ivqE31NNaWY8B+5Yh/W4h6Eh5vF61Hxr3MUnqbRdnSg90czL63PWqF01DZ2riCrc91N+ XS7o9wM+pRHbT9Oq6pL8Q1513PrvWJzIUKtEv8tS8T+UvyOae26KjokmN/e2A9N89828 FYCA== X-Gm-Message-State: ALKqPwfR0e7MziB63e91Pf6qCci8yAVdZBeaFiOBMkkeCD8bsvo3yN/e 3brVt0ETOPkRD2B09hZr5nAGCQ== X-Received: by 2002:adf:b053:: with SMTP id g19-v6mr5578780wra.128.1527777930297; Thu, 31 May 2018 07:45:30 -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.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 May 2018 07:45:29 -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 2/4] block, bfq: remove slow-system class Date: Thu, 31 May 2018 16:45:06 +0200 Message-Id: <20180531144508.3927-3-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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org BFQ computes the duration of weight raising for interactive applications automatically, using some reference parameters. In particular, BFQ uses the best durations (see comments in the code for how these durations have been assessed) for two classes of systems: slow and fast ones. Examples of slow systems are old phones or systems using micro HDDs. Fast systems are all the remaining ones. Using these parameters, BFQ computes the actual duration of the weight raising, for the system at hand, as a function of the relative speed of the system w.r.t. the speed of a reference system, belonging to the same class of systems as the system at hand. This slow vs fast differentiation proved to be useful in the past, but happens to have little meaning with current hardware. Even worse, it does cause problems in virtual systems, where the speed of the system can vary frequently, and so widely to just confuse the class-detection mechanism, and, as we have verified experimentally, to cause BFQ to compute non-sensical weight-raising durations. This commit addresses this issue by removing the slow class and the class-detection mechanism. Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 137 ++++++++++++++++------------------------------------ block/bfq-iosched.h | 14 ++---- 2 files changed, 46 insertions(+), 105 deletions(-) -- 2.16.1 diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index f3703e7431aa..262c929e24ee 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -251,55 +251,43 @@ static struct kmem_cache *bfq_pool; * 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 + * duration = (ref_rate / r) * ref_wr_duration, + * where r is the peak rate of the device, and ref_rate and + * ref_wr_duration are two reference parameters. In particular, + * ref_rate is the peak rate of the reference storage device (see + * below), and ref_wr_duration is about the maximum time needed, with + * BFQ and while reading two files in parallel, to load typical large + * applications on the reference device (see the comments on + * max_service_from_wr below, for more details on how ref_wr_duration + * 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; - * . whether the device is slow, such as old or portable HDDs, as well as - * SD cards, or fast, such as newer HDDs and SSDs. + * BFQ uses two different reference pairs (ref_rate, ref_wr_duration), + * depending on whether the device is rotational or non-rotational. * - * The device's speed class is dynamically (re)detected in - * bfq_update_peak_rate() every time the estimated peak rate is updated. + * In the following definitions, ref_rate[0] and ref_wr_duration[0] + * are the reference values for a rotational device, whereas + * ref_rate[1] and ref_wr_duration[1] are the reference values for a + * non-rotational device. The reference rates are not the actual peak + * rates of the devices used as a reference, but slightly lower + * values. The reason for using slightly lower values is that the + * peak-rate estimator tends to yield slightly lower values than the + * actual peak rate (it can yield the actual peak rate only if there + * is only one process doing I/O, and the process does sequential + * I/O). * - * In the following definitions, R_slow[0]/R_fast[0] and - * T_slow[0]/T_fast[0] are the reference values for a slow/fast - * rotational device, whereas R_slow[1]/R_fast[1] and - * T_slow[1]/T_fast[1] are the reference values for a slow/fast - * non-rotational device. Finally, device_speed_thresh are the - * thresholds used to switch between speed classes. The reference - * rates are not the actual peak rates of the devices used as a - * reference, but slightly lower values. The reason for using these - * slightly lower values is that the peak-rate estimator tends to - * yield slightly lower values than the actual peak rate (it can yield - * the actual peak rate only if there is only one process doing I/O, - * and the process does sequential I/O). - * - * Both the reference peak rates and the thresholds are measured in - * sectors/usec, left-shifted by BFQ_RATE_SHIFT. + * The reference peak rates are measured in sectors/usec, left-shifted + * by BFQ_RATE_SHIFT. */ -static int R_slow[2] = {1000, 10700}; -static int R_fast[2] = {14000, 33000}; +static int ref_rate[2] = {14000, 33000}; /* - * To improve readability, a conversion function is used to initialize the - * following arrays, which entails that they can be initialized only in a - * function. + * To improve readability, a conversion function is used to initialize + * the following array, which entails that the array can be + * initialized only in a function. */ -static int T_slow[2]; -static int T_fast[2]; -static int device_speed_thresh[2]; +static int ref_wr_duration[2]; /* * BFQ uses the above-detailed, time-based weight-raising mechanism to @@ -938,7 +926,7 @@ static unsigned int bfq_wr_duration(struct bfq_data *bfqd) if (bfqd->bfq_wr_max_time > 0) return bfqd->bfq_wr_max_time; - dur = bfqd->RT_prod; + dur = bfqd->rate_dur_prod; do_div(dur, bfqd->peak_rate); /* @@ -2543,37 +2531,15 @@ static unsigned long bfq_calc_max_budget(struct bfq_data *bfqd) /* * Update parameters related to throughput and responsiveness, as a * function of the estimated peak rate. See comments on - * bfq_calc_max_budget(), and on T_slow and T_fast arrays. + * bfq_calc_max_budget(), and on the ref_wr_duration array. */ static void update_thr_responsiveness_params(struct bfq_data *bfqd) { - int dev_type = blk_queue_nonrot(bfqd->queue); - - if (bfqd->bfq_user_max_budget == 0) + if (bfqd->bfq_user_max_budget == 0) { bfqd->bfq_max_budget = bfq_calc_max_budget(bfqd); - - if (bfqd->device_speed == BFQ_BFQD_FAST && - bfqd->peak_rate < device_speed_thresh[dev_type]) { - bfqd->device_speed = BFQ_BFQD_SLOW; - bfqd->RT_prod = R_slow[dev_type] * - T_slow[dev_type]; - } else if (bfqd->device_speed == BFQ_BFQD_SLOW && - bfqd->peak_rate > device_speed_thresh[dev_type]) { - bfqd->device_speed = BFQ_BFQD_FAST; - bfqd->RT_prod = R_fast[dev_type] * - T_fast[dev_type]; + bfq_log(bfqd, "new max_budget = %d", bfqd->bfq_max_budget); } - - bfq_log(bfqd, -"dev_type %s dev_speed_class = %s (%llu sects/sec), thresh %llu setcs/sec", - dev_type == 0 ? "ROT" : "NONROT", - bfqd->device_speed == BFQ_BFQD_FAST ? "FAST" : "SLOW", - bfqd->device_speed == BFQ_BFQD_FAST ? - (USEC_PER_SEC*(u64)R_fast[dev_type])>>BFQ_RATE_SHIFT : - (USEC_PER_SEC*(u64)R_slow[dev_type])>>BFQ_RATE_SHIFT, - (USEC_PER_SEC*(u64)device_speed_thresh[dev_type])>> - BFQ_RATE_SHIFT); } static void bfq_reset_rate_computation(struct bfq_data *bfqd, @@ -5279,14 +5245,12 @@ static int bfq_init_queue(struct request_queue *q, struct elevator_type *e) bfqd->wr_busy_queues = 0; /* - * Begin by assuming, optimistically, that the device is a - * high-speed one, and that its peak rate is equal to 2/3 of - * the highest reference rate. + * Begin by assuming, optimistically, that the device peak + * rate is equal to 2/3 of the highest reference rate. */ - bfqd->RT_prod = R_fast[blk_queue_nonrot(bfqd->queue)] * - T_fast[blk_queue_nonrot(bfqd->queue)]; - bfqd->peak_rate = R_fast[blk_queue_nonrot(bfqd->queue)] * 2 / 3; - bfqd->device_speed = BFQ_BFQD_FAST; + bfqd->rate_dur_prod = ref_rate[blk_queue_nonrot(bfqd->queue)] * + ref_wr_duration[blk_queue_nonrot(bfqd->queue)]; + bfqd->peak_rate = ref_rate[blk_queue_nonrot(bfqd->queue)] * 2 / 3; spin_lock_init(&bfqd->lock); @@ -5593,8 +5557,8 @@ static int __init bfq_init(void) /* * Times to load large popular applications for the typical * systems installed on the reference devices (see the - * comments before the definitions of the next two - * arrays). Actually, we use slightly slower values, as the + * comments before the definition of the next + * array). Actually, we use slightly lower values, as the * estimated peak rate tends to be smaller than the actual * peak rate. The reason for this last fact is that estimates * are computed over much shorter time intervals than the long @@ -5603,25 +5567,8 @@ static int __init bfq_init(void) * scheduler cannot rely on a peak-rate-evaluation workload to * be run for a long time. */ - T_slow[0] = msecs_to_jiffies(3500); /* actually 4 sec */ - T_slow[1] = msecs_to_jiffies(6000); /* actually 6.5 sec */ - T_fast[0] = msecs_to_jiffies(7000); /* actually 8 sec */ - T_fast[1] = msecs_to_jiffies(2500); /* actually 3 sec */ - - /* - * Thresholds that determine the switch between speed classes - * (see the comments before the definition of the array - * device_speed_thresh). These thresholds are biased towards - * transitions to the fast class. This is safer than the - * opposite bias. In fact, a wrong transition to the slow - * class results in short weight-raising periods, because the - * speed of the device then tends to be higher that the - * reference peak rate. On the opposite end, a wrong - * transition to the fast class tends to increase - * weight-raising periods, because of the opposite reason. - */ - device_speed_thresh[0] = (4 * R_slow[0]) / 3; - device_speed_thresh[1] = (4 * R_slow[1]) / 3; + ref_wr_duration[0] = msecs_to_jiffies(7000); /* actually 8 sec */ + ref_wr_duration[1] = msecs_to_jiffies(2500); /* actually 3 sec */ ret = elv_register(&iosched_bfq_mq); if (ret) diff --git a/block/bfq-iosched.h b/block/bfq-iosched.h index ae2f3dadec44..b5678cc8cfa1 100644 --- a/block/bfq-iosched.h +++ b/block/bfq-iosched.h @@ -399,11 +399,6 @@ struct bfq_io_cq { struct bfq_ttime saved_ttime; }; -enum bfq_device_speed { - BFQ_BFQD_FAST, - BFQ_BFQD_SLOW, -}; - /** * struct bfq_data - per-device data structure. * @@ -611,12 +606,11 @@ struct bfq_data { /* Max service-rate for a soft real-time queue, in sectors/sec */ unsigned int bfq_wr_max_softrt_rate; /* - * Cached value of the product R*T, used for computing the - * maximum duration of weight raising automatically. + * Cached value of the product ref_rate*ref_wr_duration, used + * for computing the maximum duration of weight raising + * automatically. */ - u64 RT_prod; - /* device-speed class for the low-latency heuristic */ - enum bfq_device_speed device_speed; + u64 rate_dur_prod; /* fallback dummy bfqq for extreme OOM conditions */ struct bfq_queue oom_bfqq; From patchwork Thu May 31 14:45:07 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 137419 Delivered-To: patch@linaro.org Received: by 2002:a2e:9706:0:0:0:0:0 with SMTP id r6-v6csp6691927lji; Thu, 31 May 2018 07:46:06 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJHsZxqxF9knc1NpoS+Mifdwjws92qBETJAY6px+3Lj8JSeI6WT+Gp1289uHeOpNcs3DWRk X-Received: by 2002:a17:902:1a6:: with SMTP id b35-v6mr7257734plb.80.1527777966579; Thu, 31 May 2018 07:46:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527777966; cv=none; d=google.com; s=arc-20160816; b=ek4aXw/mUeLPN2gGqzMZ4CMesF1/mNXvlEEL4QBZ1iqGnjgLzhhUEF5LSAQ9iF2oaR BmXjb2UgqGJpdMq/3IlT2r9JyPVUBKq71lynVhJ1wFOPfm7f3Tp1eF7HAh9vYGwlsQw+ xD0ktm4StLpR8EHxYZVevuDrtfTG8/gj/MDLq+RseF5qjw8qlOo3xDAWdpY+AKYupIHv xAdaqYGoytY239TKKsUFu5S937Tx4flAZau5FK6uSWeU7uBARfcP2NfDz4KQTWutOZNz cgmwIaQoJBU4b1LRJeLmTPz8HQ4i/uZpIydWvZcvhlDv9beIDq70hxfxKKeWfOn3PRdi 39Cw== 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=OXEYZyoVidrAtqd+nqmbdenmsTMXMPcHkxKsAlNM+es=; b=HDc7wNSFyf/VMG2rbzcPDTQ1mIyORpuh7MZGIyxWV1oZIQMENg7Yk3JWR69v7JwSIO M49i9dPZH+HInjdfNTQqGqlGVVk4lr/Xwokv3gKDbSV+AHZqG5T4S5xWdcM5LDIKed81 gnzqc0EWko/2YWu8pq5ooyiLVZuQTOV3Lwf1D+gKOsUg+PekUA2q4nX0iWTRLOi9PzqS bOtSRe2K18HTW4MZnizayJxxEC2D7CBDylyrPfBbp0vjBajvxzMVNNivL9UBigLd/+E3 5D8BbtwlJ9qSS9fePadT71wGsfbxwjYHMR1KcWmfhZWUz9Rcd4vnSwp35xhdgO2p4HOV feWA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=TDFC/ifE; 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 p91-v6si37495154plb.457.2018.05.31.07.46.06; Thu, 31 May 2018 07:46:06 -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=TDFC/ifE; 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 S1755489AbeEaOqD (ORCPT + 30 others); Thu, 31 May 2018 10:46:03 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:51116 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755441AbeEaOpd (ORCPT ); Thu, 31 May 2018 10:45:33 -0400 Received: by mail-wm0-f67.google.com with SMTP id t11-v6so54546755wmt.0 for ; Thu, 31 May 2018 07:45:32 -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=OXEYZyoVidrAtqd+nqmbdenmsTMXMPcHkxKsAlNM+es=; b=TDFC/ifE1oOjwgDhQ/4FqouSeNpmLb3g3w8QvEnoOoOM1bJncROGT7nyBIPrlpDlEA i9xcVpfawyyPMv9P67qTyKWGnvQ1EeGI+ezX9ixXgRuXMyjRjvsGmRnMaK7UzEuWTO/z 71eIpPmdMI0bErfCsbK1Xoco/XMSFRFGkJBMY= 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=OXEYZyoVidrAtqd+nqmbdenmsTMXMPcHkxKsAlNM+es=; b=BaPO7Djm2yfsGjuT9JRuZOAP2lZbU5GelzB5aj1ouOT6d3MloLC0ZKpX+8Z1Te64Ml w4+BBflm43GlUCJa/Q+oJmoLqbDcfMf7HeFyiOTXr/8iyCc3DYIlAgM2Y6t7jD+tVBrL 7/KcX3Ih4GnVbfps1VV29QGDSh2A999wdHGEcr54TZ/KSOMpoh4L9SUkjHFD03tNwZif BM1n23fNOYzx+V4mqg2dFKeL542ikwpWjnec1TSIwLm2vZZpvb2euH3dbpsL9oMbsRzq iZ93dQVfyxTtkiodcDMp5pYJZae8CVCNDJTiVaonyE1c02qcbjuC+VQ7gGigj6HFvoRO Ha1A== X-Gm-Message-State: APt69E29HtqAXeDwfy1SiGUacfqUXEZhOnQ2jeq0oo0uMxfQrjObYUwg LgI9MFRjz+XZMLt5Rb9Pge4R/A== X-Received: by 2002:a1c:f70b:: with SMTP id v11-v6mr125621wmh.77.1527777931700; Thu, 31 May 2018 07:45:31 -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.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 May 2018 07:45:30 -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 3/4] block, bfq: increase weight-raising duration for interactive apps Date: Thu, 31 May 2018 16:45:07 +0200 Message-Id: <20180531144508.3927-4-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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Davide Sapienza The maximum possible duration of the weight-raising period for interactive applications is limited to 13 seconds, as this is the time needed to load the largest application that we considered when tuning weight raising. Unfortunately, in such an evaluation, we did not consider the case of very slow virtual machines. For example, on a QEMU/KVM virtual machine - running in a slow PC; - with a virtual disk stacked on a slow low-end 5400rpm HDD; - serving a heavy I/O workload, such as the sequential reading of several files; mplayer takes 23 seconds to start, if constantly weight-raised. To address this issue, this commit conservatively sets the upper limit for weight-raising duration to 25 seconds. Signed-off-by: Davide Sapienza Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) -- 2.16.1 diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 262c929e24ee..31ce089d54eb 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -930,22 +930,26 @@ static unsigned int bfq_wr_duration(struct bfq_data *bfqd) do_div(dur, bfqd->peak_rate); /* - * Limit duration between 3 and 13 seconds. Tests show that - * higher values than 13 seconds often yield the opposite of - * the desired result, i.e., worsen responsiveness by letting - * non-interactive and non-soft-real-time applications - * preserve weight raising for a too long time interval. + * Limit duration between 3 and 25 seconds. The upper limit + * has been conservatively set after the following worst case: + * on a QEMU/KVM virtual machine + * - running in a slow PC + * - with a virtual disk stacked on a slow low-end 5400rpm HDD + * - serving a heavy I/O workload, such as the sequential reading + * of several files + * mplayer took 23 seconds to start, if constantly weight-raised. + * + * As for higher values than that accomodating the above bad + * scenario, tests show that higher values would often yield + * the opposite of the desired result, i.e., would worsen + * responsiveness by allowing non-interactive applications to + * preserve weight raising for too long. * * On the other end, lower values than 3 seconds make it * difficult for most interactive tasks to complete their jobs * before weight-raising finishes. */ - if (dur > msecs_to_jiffies(13000)) - dur = msecs_to_jiffies(13000); - else if (dur < msecs_to_jiffies(3000)) - dur = msecs_to_jiffies(3000); - - return dur; + return clamp_val(dur, msecs_to_jiffies(3000), msecs_to_jiffies(25000)); } /* switch back from soft real-time to interactive weight raising */ From patchwork Thu May 31 14:45:08 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 137418 Delivered-To: patch@linaro.org Received: by 2002:a2e:9706:0:0:0:0:0 with SMTP id r6-v6csp6691586lji; Thu, 31 May 2018 07:45:50 -0700 (PDT) X-Google-Smtp-Source: ADUXVKL2pVJ87dT6gyC0onyG1EHykjm9zD1LRY5XKV/jgDcvI6KtWLLxQqxxRAgbBbozEqElBhDe X-Received: by 2002:a17:902:206:: with SMTP id 6-v6mr7199728plc.294.1527777950762; Thu, 31 May 2018 07:45:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527777950; cv=none; d=google.com; s=arc-20160816; b=Ty1OnF+mnYQNFw6VlUR+AmxswRgUS467ZEEhIFpY9nKbGgtbIF+LUL48AOma3KdgS2 Vqrpild5LDJ1KrVnUv1AsA5NpiHQsV7KsStLvAVLCYg2visPua3fe0g29SYoBGFGFx0/ LCTXVZ1Ke01k86EpqHDZbpDYdbNRPdsmP8cB5BI3PU9ZHPrqrd8+KRi0VVE7czyiNVHu 13uCzWenHFTCiJXT5oD6t2Zk/AUd+NkaT6cUQPHxEFL/MSGIWmLz6qubEEsAyVzFqF2u Q7vkSL7mJrkIAQ3wtXyUzyPyWFVlqzmtRbrazH+jpe06gTeqcKmRvMfCzD+PmTzG333b xeoQ== 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=/0Hf7SCJj6Y7ejeDOkPs34vFaFRY+69k50LwZc5XXqI=; b=ZRvdOD/cHtmaePlhABVQHaJ1wAZvthSVe6gg+g3tUKm3qvbAoD7ieVGtqBlgI85BfU vm2rwA0iLhhyItbEPl0iI5kpPc+o47w5SG7Pnr07JmVzW41vUJeE8f5my7KdHJARs+4m wNHWPgOQWk5s06RLDUlqN5Gw2Kh560udcBEll3Mc2FpPnyZaO9TlEtKjfT/nC4+85D7T OTw8HQP4d8/+mwcFyZCrR/9f8KxEbFSeG//RjZJSCK7YUYJNaVvr74jn29EapLYGzIfc 7IiITrQFf32PSRfSv9kXEoIMp/1eJrnDt3eE+DWUn441R5a2PzFOwNZkTm+B/PJR4NHY hkqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=hOZ+FKI/; 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 u6-v6si9670914pgb.226.2018.05.31.07.45.50; Thu, 31 May 2018 07:45:50 -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=hOZ+FKI/; 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 S1755476AbeEaOpr (ORCPT + 30 others); Thu, 31 May 2018 10:45:47 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:56148 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755438AbeEaOpe (ORCPT ); Thu, 31 May 2018 10:45:34 -0400 Received: by mail-wm0-f66.google.com with SMTP id a8-v6so54466197wmg.5 for ; Thu, 31 May 2018 07:45: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:in-reply-to:references; bh=/0Hf7SCJj6Y7ejeDOkPs34vFaFRY+69k50LwZc5XXqI=; b=hOZ+FKI/1edNxA6XLKxJHDCcgDilTJKv/OvhypdNUmRPGexLtBqVdEZajrW70jaIQn Tx72g0l1XvmsARF8mXaaEqJKmT8fz/LfXDbEx1/ncvQjFXjuq7GQjhF19WWHvi2i5+JI KGW+gRaHx2o952O8/7JnndJ0ew29p5hfjH4Ws= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=/0Hf7SCJj6Y7ejeDOkPs34vFaFRY+69k50LwZc5XXqI=; b=YjrIwRzD4TwMnPSzMbes9mutIQGo2QIYtqyYqZKreVnBcVqo2MOnvZ3hq0NeeDCBNZ rwa09MOh9W+on/1YHA63QIZhp1yT8QYt2f9sC32/sd4poqNErM2jb5WJzbg8Wzd1hxAG HY8If+tthsQsKgJARnGhiJqTnk+XC/2y2i54O7ygPJmX0D8kScU3UZVs5oLZyKZtMjWR pD2saLlfHtytN4FTyF9NEYM16fbpdLMOMYo+Ha06uBR7o5OENBw5KMwdJzkqzH9GBmaw S0nou4F65QfgE11u2e1Odl17+TW71yQAlRRU4DMpd4QD9672xkO1xcBGI+pRp+2ToehD RHPA== X-Gm-Message-State: ALKqPwfqsgxtlFB+5HMUYdL7X5ceoP/2v3k48W9EBEgGgQVq18On11j1 tIQK3tOzELAcR9hbo4MmTIRkrg== X-Received: by 2002:a1c:6a1a:: with SMTP id f26-v6mr179479wmc.1.1527777933040; Thu, 31 May 2018 07:45:33 -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.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 May 2018 07:45:32 -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 4/4] block, bfq: prevent soft_rt_next_start from being stuck at infinity Date: Thu, 31 May 2018 16:45:08 +0200 Message-Id: <20180531144508.3927-5-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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Davide Sapienza BFQ can deem a bfq_queue as soft real-time only if the queue - periodically becomes completely idle, i.e., empty and with no still-outstanding I/O request; - after becoming idle, gets new I/O only after a special reference time soft_rt_next_start. In this respect, after commit "block, bfq: consider also past I/O in soft real-time detection", the value of soft_rt_next_start can never decrease. This causes a problem with the following special updating case for soft_rt_next_start: to prevent queues that are not completely idle to be wrongly detected as soft real-time (when they become non-empty again), soft_rt_next_start is temporarily set to infinity for empty queues with still outstanding I/O requests. But, if such an update is actually performed, then, because of the above commit, soft_rt_next_start will be stuck at infinity forever, and the queue will have no more chance to be considered soft real-time. On slow systems, this problem does cause actual soft real-time applications to be occasionally not detected as such. This commit addresses this issue by eliminating the pushing of soft_rt_next_start to infinity, and by changing the way non-empty queues are prevented from being wrongly detected as soft real-time. Simply, a queue that becomes non-empty again can now be detected as soft real-time only if it has no outstanding I/O request. Signed-off-by: Davide Sapienza Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 29 ++--------------------------- 1 file changed, 2 insertions(+), 27 deletions(-) -- 2.16.1 diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 31ce089d54eb..37cadc643c56 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -1416,15 +1416,6 @@ static bool bfq_bfqq_update_budg_for_activation(struct bfq_data *bfqd, return wr_or_deserves_wr; } -/* - * Return the farthest future time instant according to jiffies - * macros. - */ -static unsigned long bfq_greatest_from_now(void) -{ - return jiffies + MAX_JIFFY_OFFSET; -} - /* * Return the farthest past time instant according to jiffies * macros. @@ -1569,7 +1560,8 @@ static void bfq_bfqq_handle_idle_busy_switch(struct bfq_data *bfqd, in_burst = bfq_bfqq_in_large_burst(bfqq); soft_rt = bfqd->bfq_wr_max_softrt_rate > 0 && !in_burst && - time_is_before_jiffies(bfqq->soft_rt_next_start); + time_is_before_jiffies(bfqq->soft_rt_next_start) && + bfqq->dispatched == 0; *interactive = !in_burst && idle_for_long_time; wr_or_deserves_wr = bfqd->low_latency && (bfqq->wr_coeff > 1 || @@ -3272,23 +3264,6 @@ void bfq_bfqq_expire(struct bfq_data *bfqd, bfqq->soft_rt_next_start = bfq_bfqq_softrt_next_start(bfqd, bfqq); else { - /* - * The application is still waiting for the - * completion of one or more requests: - * prevent it from possibly being incorrectly - * deemed as soft real-time by setting its - * soft_rt_next_start to infinity. In fact, - * without this assignment, the application - * would be incorrectly deemed as soft - * real-time if: - * 1) it issued a new request before the - * completion of all its in-flight - * requests, and - * 2) at that time, its soft_rt_next_start - * happened to be in the past. - */ - bfqq->soft_rt_next_start = - bfq_greatest_from_now(); /* * Schedule an update of soft_rt_next_start to when * the task may be discovered to be isochronous.