From patchwork Sat Jun 19 14:09:42 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 12332991 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=-18.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham 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 75AA8C49361 for ; Sat, 19 Jun 2021 14:10:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4DF1161168 for ; Sat, 19 Jun 2021 14:10:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234210AbhFSOMU (ORCPT ); Sat, 19 Jun 2021 10:12:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48222 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234100AbhFSOMT (ORCPT ); Sat, 19 Jun 2021 10:12:19 -0400 Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 75805C061756 for ; Sat, 19 Jun 2021 07:10:06 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id c5so14115504wrq.9 for ; Sat, 19 Jun 2021 07:10:06 -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 :mime-version:content-transfer-encoding; bh=6g7vlVbhoRZSF7+EmrRdxzOP/EHGvFfqkkjwETya/KE=; b=kjMBUY3h3UMTyLQUbc28lJ70mF0Ggl/Z+C4o5tHPUcVFtGPII28NP36weIPnVxdIw3 sWpCjcYZVo4izzyMLTgvzAaJCod4JxphZYTUjdwkBnBFMkp5iiO92vxK0lJmiuQmjjGU uyJdIGWuKnkQBGFb7Ts12IHJLjx7g2xC3rxUPdgWLMr0JFAWQn2lD35IBq17SmtBLUio DQx3TGmzOId64bieow58imzwYQ8fPTgcwSyR41v0tYXK6A/RbVUOXBIVYozdZt/wZRYD Lfn0W0VOyEKeeXhKFrO9wYGp8N0t74qgDWdqWM5as8c1jxeJTW2+AhTRHih6Rl/7KdGm MJ7g== 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:mime-version:content-transfer-encoding; bh=6g7vlVbhoRZSF7+EmrRdxzOP/EHGvFfqkkjwETya/KE=; b=ksvaHXTzlwh0zAaUHPKK/nlh3KV6i4uF+0FpS7uURvrDqjRhkG4Lrtr3rhbNOhpZAj yyv3t4CPEJirsHt4+qJUDeSZvubQ0kCn6ocyXj+ADZEQvTQLTdWRfhvGKabwoLaWXJsR 7vWxUz/1REQznKiXeP9pwGkhjQQlCwkaAEdtZzzKF5pbgEcpko3VSU1zTEZ8H2l5J9PA qJNOQwy2wVWQ2Iu/rlZn+9XXAA+OsfeImmY/hb4AfSm/rokZE9Bx8avo0d3McwWej+Wp 0sVaA9yMtfHcN5Ejfy+lEuo4LuXUK/2d8ZFWdcwQSjtUWrPIoE3M35XXzRaWbnagCsX7 LqPg== X-Gm-Message-State: AOAM530lpWyN/pwlOYBrIBOuOswFVfiFvC/1tcQk16EZI7dQkMFwS45B s/e7nvhDH/DNn8Bo3M2U0hupCw== X-Google-Smtp-Source: ABdhPJwJHJqgwj+z7ObRlMdOuqA4Jx8jhBKQRQmNXinJqXxj94gI8wVZ5HhsevkGxDk8YxEoIqWRig== X-Received: by 2002:adf:a34e:: with SMTP id d14mr18045203wrb.325.1624111804985; Sat, 19 Jun 2021 07:10:04 -0700 (PDT) Received: from localhost.localdomain ([83.216.184.132]) by smtp.gmail.com with ESMTPSA id y16sm8379350wrp.51.2021.06.19.07.10.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Jun 2021 07:10:04 -0700 (PDT) From: Paolo Valente To: Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, mariottiluca1@hotmail.it, holger@applied-asynchrony.com, pedroni.pietro.96@gmail.com, Paolo Valente Subject: [PATCH FIXES/IMPROVEMENTS 1/7] block, bfq: let also stably merged queues enjoy weight raising Date: Sat, 19 Jun 2021 16:09:42 +0200 Message-Id: <20210619140948.98712-2-paolo.valente@linaro.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20210619140948.98712-1-paolo.valente@linaro.org> References: <20210619140948.98712-1-paolo.valente@linaro.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org Merged bfq_queues are kept out of weight-raising (low-latency) mechanisms. The reason is that these queues are usually created for non-interactive and non-soft-real-time tasks. Yet this is not the case for stably-merged queues. These queues are merged just because they are created shortly after each other. So they may easily serve the I/O of an interactive or soft-real time application, if the application happens to spawn multiple processes. To address this issue, this commits lets also stably-merged queued enjoy weight raising. Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index acd1f881273e..da2363f12e53 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -1729,10 +1729,23 @@ static void bfq_bfqq_handle_idle_busy_switch(struct bfq_data *bfqd, bfqq->entity.new_weight == 40; *interactive = !in_burst && idle_for_long_time && bfqq->entity.new_weight == 40; + /* + * Merged bfq_queues are kept out of weight-raising + * (low-latency) mechanisms. The reason is that these queues + * are usually created for non-interactive and + * non-soft-real-time tasks. Yet this is not the case for + * stably-merged queues. These queues are merged just because + * they are created shortly after each other. So they may + * easily serve the I/O of an interactive or soft-real time + * application, if the application happens to spawn multiple + * processes. So let also stably-merged queued enjoy weight + * raising. + */ wr_or_deserves_wr = bfqd->low_latency && (bfqq->wr_coeff > 1 || (bfq_bfqq_sync(bfqq) && - bfqq->bic && (*interactive || soft_rt))); + (bfqq->bic || RQ_BIC(rq)->stably_merged) && + (*interactive || soft_rt))); /* * Using the last flag, update budget and check whether bfqq From patchwork Sat Jun 19 14:09:43 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 12332993 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=-18.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham 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 AE998C2B9F4 for ; Sat, 19 Jun 2021 14:10:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8A8A761154 for ; Sat, 19 Jun 2021 14:10:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233984AbhFSOMW (ORCPT ); Sat, 19 Jun 2021 10:12:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48232 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234201AbhFSOMT (ORCPT ); Sat, 19 Jun 2021 10:12:19 -0400 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 74290C061574 for ; Sat, 19 Jun 2021 07:10:08 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id a11so14124369wrt.13 for ; Sat, 19 Jun 2021 07:10:08 -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 :mime-version:content-transfer-encoding; bh=hC9BFTBWcTXijFEq33PLLX9kxhkfj/7LaHyPw7jQ58s=; b=o8TzPa/l1bjhf7QJVAWLMR7BvlUNSL2urpFZoxSIhTmfqBGcnsBJw7OA6e3Rt4C8OV QqWe4sjJN01SsrIwPExwmMqiyupkYW2MDoPs8amz1eO11np7bkZVz9DfPlgXhdzyKTwX M1NuodJ+rSZBRbpYU/BuSXrx7RSnNoT+GuBDA8UlYGoNivTeTHEScEVIGEdtziwVXFnu IFbIEMmAp4WQo0tuGRO+9ueJEY0rSMZnZHf1vo89ELIOgyH05SSXiZ9vgkZSHm6TVAiZ Nbsm8KKhpBWJZrpTUH/WwvFMFpmfp/W+uM8p/rVXvfN+QrU2/Mxi1+1fx0KuyzEL6tla so9Q== 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:mime-version:content-transfer-encoding; bh=hC9BFTBWcTXijFEq33PLLX9kxhkfj/7LaHyPw7jQ58s=; b=IWrk+XtmK9DPEXgVxrhxh+z6xdDMkcAZ9o4riF+3jksowJGTHOFKqlEYHdKI0SE6Lx GHs1bOwOOw9dA+PXhq5G+KZl4lHjPPE+tR0yQVmsO55XCZNKAK6VOvWjpQJPS0uwTM3Z VDyzZBbAsk50DtRAQ3mrCztWZpw3LO1Rf4phd6LE1qv+i+1M85CxbYHCf0eku752U3Xg ROoCi6oCBRVAjqp6FKN4tuFxv5EnzAIem0OG/x5PpwgBs78e1IbLt6s4/PivFvwXACNN 0NDLBLEvqN6Prksx24GDsnj7ODTPZAut3bma915sQ6hpO18lpw4iloexzVyAtV2lNhv4 rOGA== X-Gm-Message-State: AOAM530u/037IKBQ0gLzwjXBQZyegLx8y9lMk4sZGRQuGMNu36Z+eeEO n5fgQEBBOFFnEdhAHOJAuwBJuQ== X-Google-Smtp-Source: ABdhPJw9VMfy19IWy4r4JaRGj+svzFwY0ZUiywgiyFidMcYz1RGQ9K//Rs9Lj8yf8hpJ1JrLCDVicw== X-Received: by 2002:a5d:558e:: with SMTP id i14mr17953487wrv.16.1624111806981; Sat, 19 Jun 2021 07:10:06 -0700 (PDT) Received: from localhost.localdomain ([83.216.184.132]) by smtp.gmail.com with ESMTPSA id y16sm8379350wrp.51.2021.06.19.07.10.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Jun 2021 07:10:05 -0700 (PDT) From: Paolo Valente To: Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, mariottiluca1@hotmail.it, holger@applied-asynchrony.com, pedroni.pietro.96@gmail.com, Paolo Valente Subject: [PATCH FIXES/IMPROVEMENTS 2/7] block, bfq: fix delayed stable merge check Date: Sat, 19 Jun 2021 16:09:43 +0200 Message-Id: <20210619140948.98712-3-paolo.valente@linaro.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20210619140948.98712-1-paolo.valente@linaro.org> References: <20210619140948.98712-1-paolo.valente@linaro.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org From: Luca Mariotti When attempting to schedule a merge of a given bfq_queue with the currently in-service bfq_queue or with a cooperating bfq_queue among the scheduled bfq_queues, delayed stable merge is checked for rotational or non-queueing devs. For this stable merge to be performed, some conditions must be met. If the current bfq_queue underwent some split from some merged bfq_queue, one of these conditions is that two hundred milliseconds must elapse from split, otherwise this condition is always met. Unfortunately, by mistake, time_is_after_jiffies() was written instead of time_is_before_jiffies() for this check, verifying that less than two hundred milliseconds have elapsed instead of verifying that at least two hundred milliseconds have elapsed. Fix this issue by replacing time_is_after_jiffies() with time_is_before_jiffies(). Signed-off-by: Luca Mariotti Signed-off-by: Paolo Valente Signed-off-by: Pietro Pedroni --- block/bfq-iosched.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index da2363f12e53..c5c0e74977d4 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -2710,7 +2710,7 @@ bfq_setup_cooperator(struct bfq_data *bfqd, struct bfq_queue *bfqq, if (unlikely(!bfqd->nonrot_with_queueing)) { if (bic->stable_merge_bfqq && !bfq_bfqq_just_created(bfqq) && - time_is_after_jiffies(bfqq->split_time + + time_is_before_jiffies(bfqq->split_time + msecs_to_jiffies(200))) { struct bfq_queue *stable_merge_bfqq = bic->stable_merge_bfqq; From patchwork Sat Jun 19 14:09:44 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 12332995 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=-18.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham 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 64C0CC49361 for ; Sat, 19 Jun 2021 14:10:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4BD93610EA for ; Sat, 19 Jun 2021 14:10:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234201AbhFSOMX (ORCPT ); Sat, 19 Jun 2021 10:12:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48238 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234265AbhFSOMV (ORCPT ); Sat, 19 Jun 2021 10:12:21 -0400 Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A0DF5C061574 for ; Sat, 19 Jun 2021 07:10:09 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id r9so14112638wrz.10 for ; Sat, 19 Jun 2021 07:10:09 -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 :mime-version:content-transfer-encoding; bh=CUWJdjp8QRxQ/u+DTP4tjJp/xb4db7Dn4angKhvJAxI=; b=vrWLuh4KzKECdtkDHypvz5aUkJHB2FxS7IccXvXbvXhnwl7wr9nEmx7dapAGxWXyOq POFNHr2tl3dK9ORgnPTsymDwYi8iFXRhxL43cezdIhFvuJkE4dVkO+NNgAMMooWcHwST Cdyjkbwz2XyPFthDYvPr2C8xtTM8Gsz7BYPht8+2eMemoQz365pJMEgmvtz0NEneDtsT Wqa++GYLzRNIAGYXEiymcfiPZDQkU/QHqKWMESTvT9HeLzgw/HOzz79ynvRuDoskygUm PsTLzVkm785MAEsuVWWeTg/chW9vYY/rBy9CFFrEcYcp+eriKGvrgV1KkFFcV45CJVGg /+Tg== 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:mime-version:content-transfer-encoding; bh=CUWJdjp8QRxQ/u+DTP4tjJp/xb4db7Dn4angKhvJAxI=; b=PbaXs050L4T4qsUpy1MgOBg/zx9Eo2qw3EZYdp822Su+T+YNl3Oqrvh+tRUOExZBcc tZycOFhT6gMgGUcB3Wvpw3gPqtmR7wTswBhFsmv9BzKJSSVSnSAIaob9NtARJ3sO/4rm YGk+4MVcubFUykFIDcI961Mp5Xg1US3dKKPFdi8oUiCz9tWc+M6qW7Ul//7QDOuyLyLD wG2Qaj4yTix6TDn9JY2F+sl94UlIu9jV2TnLeRck7Tivdv7t9Cc4D1CpoV26m19vEg0E Zpq58EU4TEJMQpL/AIrKyIXkVQRxm6vVD5/G5PdJOMAy58mTS38qgjX2MxkdHY6lKq4R j1mw== X-Gm-Message-State: AOAM532xS07ggf0zjEEMw8GKCSkPuSMjayTAimcZn3jqalHuMCetjS6S ezfx0DzAS2D1YU0GVuPkgYLwWQ== X-Google-Smtp-Source: ABdhPJz9HbZuh3IYFmvsxSzG1M6ex6Z6ryX5xaHFq2NwNqNtB4gNcDxSr7WZAzp/jRDsKMAC2NSFhQ== X-Received: by 2002:a5d:59a3:: with SMTP id p3mr18451225wrr.284.1624111808195; Sat, 19 Jun 2021 07:10:08 -0700 (PDT) Received: from localhost.localdomain ([83.216.184.132]) by smtp.gmail.com with ESMTPSA id y16sm8379350wrp.51.2021.06.19.07.10.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Jun 2021 07:10:07 -0700 (PDT) From: Paolo Valente To: Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, mariottiluca1@hotmail.it, holger@applied-asynchrony.com, pedroni.pietro.96@gmail.com, Paolo Valente Subject: [PATCH FIXES/IMPROVEMENTS 3/7] block, bfq: consider also creation time in delayed stable merge Date: Sat, 19 Jun 2021 16:09:44 +0200 Message-Id: <20210619140948.98712-4-paolo.valente@linaro.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20210619140948.98712-1-paolo.valente@linaro.org> References: <20210619140948.98712-1-paolo.valente@linaro.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org Since commit 430a67f9d616 ("block, bfq: merge bursts of newly-created queues"), BFQ may schedule a merge between a newly created sync bfq_queue and the last sync bfq_queue created. Such a merging is not performed immediately, because BFQ needs first to find out whether the newly created queue actually reaches a higher throughput if not merged at all (and in that case BFQ will not perform any stable merging). To check that, a little time must be waited after the creation of the new queue, so that some I/O can flow in the queue, and statistics on such I/O can be computed. Yet, to evaluate the above waiting time, the last split time is considered as start time, instead of the creation time of the queue. This is a mistake, because considering the split time is correct only in the following scenario. The queue undergoes a non-stable merges on the arrival of its very first I/O request, due to close I/O with some other queue. While the queue is merged for close I/O, stable merging is not considered. Yet the queue may then happen to be split, if the close I/O finishes (or happens to be a false positive). From this time on, the queue can again be considered for stable merging. But, again, a little time must elapse, to let some new I/O flow in the queue and to get updated statistics. To wait for this time, the split time is to be taken into account. Yet, if the queue does not undergo a non-stable merge on the arrival of its very first request, then BFQ immediately checks whether the stable merge is to be performed. It happens because the split time for a queue is initialized to minus infinity when the queue is created. This commit fixes this mistake by adding the missing condition. Now the check for delayed stable-merge is performed after a little time is elapsed not only from the last queue split time, but also from the creation time of the queue. Fixes: 430a67f9d616 ("block, bfq: merge bursts of newly-created queues") Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index c5c0e74977d4..2a5c1a660f3b 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -2711,7 +2711,9 @@ bfq_setup_cooperator(struct bfq_data *bfqd, struct bfq_queue *bfqq, if (bic->stable_merge_bfqq && !bfq_bfqq_just_created(bfqq) && time_is_before_jiffies(bfqq->split_time + - msecs_to_jiffies(200))) { + msecs_to_jiffies(200)) && + time_is_before_jiffies(bfqq->creation_time + + msecs_to_jiffies(200))) { struct bfq_queue *stable_merge_bfqq = bic->stable_merge_bfqq; int proc_ref = min(bfqq_process_refs(bfqq), From patchwork Sat Jun 19 14:09:45 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 12332999 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=-18.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham 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 A5CA2C49EA4 for ; Sat, 19 Jun 2021 14:10:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8719F61168 for ; Sat, 19 Jun 2021 14:10:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234063AbhFSOM0 (ORCPT ); Sat, 19 Jun 2021 10:12:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48256 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234439AbhFSOMY (ORCPT ); Sat, 19 Jun 2021 10:12:24 -0400 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E3400C061767 for ; Sat, 19 Jun 2021 07:10:10 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id m41-20020a05600c3b29b02901dcd3733f24so80660wms.1 for ; Sat, 19 Jun 2021 07:10:10 -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 :mime-version:content-transfer-encoding; bh=A7Yg6vvsf1aIcxdCOdZYfNc6DhT8YLAwUuHHaXJpVvk=; b=QoKb8ncn4vyQjGUUA7s5y8TaDHX5t21rOTW2XELQh2bxIwf0w16+o2YPHNnKUnIb4u FKj3ktR1dWpzY69xSQ/ZTZYUsdq7M+/HlWhn8kLm7Pwd1q0kZ96Yn11xpr+CkDbqmg0d wQQRxy8S7EAX5UQPaQANNQZZ5cSEDnnRXljUN8mn0PPf7GHhRl/wUzXh0ynR4XvG3gkG q3tReu9Ivs4yKH6So++SERRU8+QSvRBQNMgqXB2stAReg4FNA/W9jkJUApJww9E5QaVF p4ppNbIiYRv91tPXLa2Lk0hamkaN2zzsZ2SUPbqgnNmXF/GgUMM4XN/WF2mIrD7Y1CBA 16Qw== 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:mime-version:content-transfer-encoding; bh=A7Yg6vvsf1aIcxdCOdZYfNc6DhT8YLAwUuHHaXJpVvk=; b=b4R8oyBR4DvMs226eMWktl5ln5ZtsjDHoJKCaZPdcXjpJArW7GlMrQXcweNQemoMqp ucb4lyyK5ruIj7T5JkzoQ13XLIPVwwD2gj7mE20L9xHJWi0Eu9zSZBSDdHe0m9PX9E4q gOKs/rjMq8DXf1unE3ZCSiGaxm390zc1gnBCA9Mifp3UqXJoOSylGHOOcxY0wZtt5NPw t86UYsLtIb0QITPORSaOV0tec49qoz0l+fUqchZQO3H5aLAvW+tQdOYg0zgVFcRm9p/Z UjWei0KH/0lM7qnBj0/z1ZETVRdb/QqJNFXIbvalV4r09xpRIzBCU23O6ihLOC79boAl RngA== X-Gm-Message-State: AOAM530IQFJQBcKLVxS7XPmCNpdJI+PRjOWySj7VwcTeUqVBT397LEQV FOq4xlMMDe34PY1ueV8pJIy6YQ== X-Google-Smtp-Source: ABdhPJzzFiN0cGpugRqiSLVtrSj3RfAxbZ4ef7Y0A1/owXURJbvFWD3IIkIgAIJoThtOY8onAyhUtA== X-Received: by 2002:a05:600c:a01:: with SMTP id z1mr16703219wmp.77.1624111809427; Sat, 19 Jun 2021 07:10:09 -0700 (PDT) Received: from localhost.localdomain ([83.216.184.132]) by smtp.gmail.com with ESMTPSA id y16sm8379350wrp.51.2021.06.19.07.10.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Jun 2021 07:10:08 -0700 (PDT) From: Paolo Valente To: Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, mariottiluca1@hotmail.it, holger@applied-asynchrony.com, pedroni.pietro.96@gmail.com, Paolo Valente Subject: [PATCH FIXES/IMPROVEMENTS 4/7] block, bfq: boost throughput by extending queue-merging times Date: Sat, 19 Jun 2021 16:09:45 +0200 Message-Id: <20210619140948.98712-5-paolo.valente@linaro.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20210619140948.98712-1-paolo.valente@linaro.org> References: <20210619140948.98712-1-paolo.valente@linaro.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org From: Pietro Pedroni One of the methods with which bfq boosts throughput is by merging queues. One of the merging variants in bfq is the stable merge. This mechanism is activated between two queues only if they are created within a certain maximum time T1 from each other. Merging can happen soon or be delayed. In the second case, before merging, bfq needs to evaluate a throughput-boost parameter that indicates whether the queue generates a high throughput is served alone. Merging occurs when this throughput-boost is not high enough. In particular, this parameter is evaluated and late merging may occur only after at least a time T2 from the creation of the queue. Currently T1 and T2 are set to 180ms and 200ms, respectively. In this way the merging mechanism rarely occurs because time is not enough. This results in a noticeable lowering of the overall throughput with some workloads (see the example below). This commit introduces two constants bfq_activation_stable_merging and bfq_late_stable_merging in order to increase the duration of T1 and T2. Both the stable merging activation time and the late merging time are set to 600ms. This value has been experimentally evaluated using sqlite benchmark in the Phoronix Test Suite on a HDD. The duration of the benchmark before this fix was 111.02s, while now it has reached 97.02s, a better result than that of all the other schedulers. Signed-off-by: Pietro Pedroni Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 2a5c1a660f3b..98a42ddb1760 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -364,6 +364,16 @@ static int ref_wr_duration[2]; */ static const unsigned long max_service_from_wr = 120000; +/* + * Maximum time between the creation of two queues, for stable merge + * to be activated (in ms) + */ +static const unsigned long bfq_activation_stable_merging = 600; +/* + * Minimum time to be waited before evaluating delayed stable merge (in ms) + */ +static const unsigned long bfq_late_stable_merging = 600; + #define RQ_BIC(rq) icq_to_bic((rq)->elv.priv[0]) #define RQ_BFQQ(rq) ((rq)->elv.priv[1]) @@ -2711,9 +2721,9 @@ bfq_setup_cooperator(struct bfq_data *bfqd, struct bfq_queue *bfqq, if (bic->stable_merge_bfqq && !bfq_bfqq_just_created(bfqq) && time_is_before_jiffies(bfqq->split_time + - msecs_to_jiffies(200)) && + msecs_to_jiffies(bfq_late_stable_merging)) && time_is_before_jiffies(bfqq->creation_time + - msecs_to_jiffies(200))) { + msecs_to_jiffies(bfq_late_stable_merging))) { struct bfq_queue *stable_merge_bfqq = bic->stable_merge_bfqq; int proc_ref = min(bfqq_process_refs(bfqq), @@ -5494,7 +5504,7 @@ static struct bfq_queue *bfq_do_or_sched_stable_merge(struct bfq_data *bfqd, */ if (!last_bfqq_created || time_before(last_bfqq_created->creation_time + - bfqd->bfq_burst_interval, + msecs_to_jiffies(bfq_activation_stable_merging), bfqq->creation_time) || bfqq->entity.parent != last_bfqq_created->entity.parent || bfqq->ioprio != last_bfqq_created->ioprio || From patchwork Sat Jun 19 14:09:46 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 12332997 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=-18.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham 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 8260BC48BE5 for ; Sat, 19 Jun 2021 14:10:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5F47F61168 for ; Sat, 19 Jun 2021 14:10:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234448AbhFSOM0 (ORCPT ); Sat, 19 Jun 2021 10:12:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48262 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234429AbhFSOMY (ORCPT ); Sat, 19 Jun 2021 10:12:24 -0400 Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2176AC061760 for ; Sat, 19 Jun 2021 07:10:12 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id b3so3870839wrm.6 for ; Sat, 19 Jun 2021 07:10:11 -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 :mime-version:content-transfer-encoding; bh=zSPAxrpWy5WBZnxErtByjmy66zeZTj10pU/KsiI/8sg=; b=HvXTpRs5J3sSdl3kN4GehJwJojqFWyCpLC6YxZJlH7JmB9eCwrFBO/57quiXULgDKS TK7v1MnrJN9PbNWtue/lgIC7wzvau68haAPYDOL98xlyV+IxWrvMmaIHPSVSEgoaoSt5 Gnm1+qRid8N7/8nhyRLfTY2NKEbSm1plyXV/sTKBvfymiIvbLG0Ie/dOr09by5ewf11b iyJJUEsjIoMtFUykb6YPJ5i2KXmKOo+K5DcrdH8P80UkvJanANJZX1JetfWRaGB2TD8L 38Wd9AgrE6KZtqGQ6CZNiNcITSlfjzl6PuVPKzwEgbQUnEO4bTuh6/KY6OCSGHn/8JVD C+dQ== 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:mime-version:content-transfer-encoding; bh=zSPAxrpWy5WBZnxErtByjmy66zeZTj10pU/KsiI/8sg=; b=MQfU6Yy9OeH9M7qqB5VxlqX+gRzahS3PPwlf6eiJokWedbmVgXddC+ynpHe93jSUWH WN/9cXvjXtGbyJV1V8+kBn8nsoz20YdkgGUUL0flbHaq+zEz1Z8g54FHgBau+QMqVG4M /FGWJ+MvZGd4kETCNgO6uZjuGg+bEL+dMB1LftNEiFqojpFMrG3xlBoJSxVtX/PaBMUC 65+xUTbmomsPVoouiKQIj94fp1QaXIRRB2sE4u46FtYAy4TudQoxCJ79P+i5lGcLuQkW ndibanu2cIzXIMwtAy9UkniDf3f4nxhy5hnw0D2Nmij8DLNF51v+WX5pn9QBYhq1db6s DDOA== X-Gm-Message-State: AOAM532/lyMx+u1Apm64vX3UBUQ84eP1ihX9vl3AGSoqAIGqzx9Z/iem Bkpv0iW6VaOnaOEdLuELRk+1Kw== X-Google-Smtp-Source: ABdhPJxUgy88rE8nMFkkBALHziPCCCyMYP1MvHiX9o+AwZkzMCfSySSrr3OtnymjMzCzfzCvkEir3g== X-Received: by 2002:adf:9084:: with SMTP id i4mr17943238wri.23.1624111810664; Sat, 19 Jun 2021 07:10:10 -0700 (PDT) Received: from localhost.localdomain ([83.216.184.132]) by smtp.gmail.com with ESMTPSA id y16sm8379350wrp.51.2021.06.19.07.10.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Jun 2021 07:10:10 -0700 (PDT) From: Paolo Valente To: Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, mariottiluca1@hotmail.it, holger@applied-asynchrony.com, pedroni.pietro.96@gmail.com, Paolo Valente Subject: [PATCH FIXES/IMPROVEMENTS 5/7] block, bfq: avoid delayed merge of async queues Date: Sat, 19 Jun 2021 16:09:46 +0200 Message-Id: <20210619140948.98712-6-paolo.valente@linaro.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20210619140948.98712-1-paolo.valente@linaro.org> References: <20210619140948.98712-1-paolo.valente@linaro.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org Since commit 430a67f9d616 ("block, bfq: merge bursts of newly-created queues"), BFQ may schedule a merge between a newly created sync bfq_queue, say Q2, and the last sync bfq_queue created, say Q1. To this goal, BFQ stores the address of Q1 in the field bic->stable_merge_bfqq of the bic associated with Q2. So, when the time for the possible merge arrives, BFQ knows which bfq_queue to merge Q2 with. In particular, BFQ checks for possible merges on request arrivals. Yet the same bic may also be associated with an async bfq_queue, say Q3. So, if a request for Q3 arrives, then the above check may happen to be executed while the bfq_queue at hand is Q3, instead of Q2. In this case, Q1 happens to be merged with an async bfq_queue. This is not only a conceptual mistake, because async queues are to be kept out of queue merging, but also a bug that leads to inconsistent states. This commits simply filters async queues out of delayed merges. Fixes: 430a67f9d616 ("block, bfq: merge bursts of newly-created queues") Tested-by: Holger Hoffstätte Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 98a42ddb1760..7bf073ef9443 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -2718,7 +2718,13 @@ bfq_setup_cooperator(struct bfq_data *bfqd, struct bfq_queue *bfqq, * costly and complicated. */ if (unlikely(!bfqd->nonrot_with_queueing)) { - if (bic->stable_merge_bfqq && + /* + * Make sure also that bfqq is sync, because + * bic->stable_merge_bfqq may point to some queue (for + * stable merging) also if bic is associated with a + * sync queue, but this bfqq is async + */ + if (bfq_bfqq_sync(bfqq) && bic->stable_merge_bfqq && !bfq_bfqq_just_created(bfqq) && time_is_before_jiffies(bfqq->split_time + msecs_to_jiffies(bfq_late_stable_merging)) && From patchwork Sat Jun 19 14:09:47 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 12333001 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=-18.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham 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 A7342C49EA5 for ; Sat, 19 Jun 2021 14:10:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 964DD61154 for ; Sat, 19 Jun 2021 14:10:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234473AbhFSOM2 (ORCPT ); Sat, 19 Jun 2021 10:12:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48274 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234455AbhFSOM0 (ORCPT ); Sat, 19 Jun 2021 10:12:26 -0400 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B47AAC0617AD for ; Sat, 19 Jun 2021 07:10:13 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id n35-20020a05600c3ba3b02901cdecb6bda8so10533754wms.5 for ; Sat, 19 Jun 2021 07:10:13 -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 :mime-version:content-transfer-encoding; bh=1+zxMsyMPSpH6r8mTDKIRiZovSCCqL71anJFuwMZ+iY=; b=oh/2TLAlejpV4LagMn+tCDQUivZCaMX6ouGYYCbwM64s4OHfAjHgMLwDq7E41Mgasr N5YY076yGSO9yRwim8Qvt0ctOcGLox0xZ0Zwkgus7eWPlvOu0yFLane8G/KZzP6fATz1 QPxFTMvnyLPhCg/rhmVnGJydUQ0lBP39ezf70n4m+4VN6z4FyDb6Nxk5c8LvNEpl60iy eWEiOrBMBPj5e1y+2OK7+uPFR8chQmJdekqhw8qCQSOFoMzbGCpEPySvv1w8iEySZXd+ ldu74XvzoVyebfCwpuOG97ob97xkbiYwOdWmmUhh++SP3/vjsc7jM6+ZjGynBy+MyP4E 5GKg== 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:mime-version:content-transfer-encoding; bh=1+zxMsyMPSpH6r8mTDKIRiZovSCCqL71anJFuwMZ+iY=; b=UF6iPZ2CBRvUuc8E1CFgV9JtRs5Zc1QiL+q38hpBPqxSkzqZ48XnWCCpMTVPF3xnEz YQWfEcXKCP/PPPOrzeKppx24pgHO/6lApJNifRc4luhKJmjJ4bvYC/rRBpfVZItgV8Kw VN70phBo8XXb9yYlyi8lhZNADhQoiVvwSbHVlbQkBRNWt7dCO5n5omJfjISCZ2fx8rBF mGTMV6s7ZcBKL5+kmFViqrWMy8twa583uax5tRDX9uCWSHql2J7Uyt+4V0+IUG9/rmN8 6XtWuOj1mKBhL9GWYhaO7kJhY5VzFK4gI6ukdAHb8DeWq3nobiH6Ul+cb0zl+lfi9c9S y0Zw== X-Gm-Message-State: AOAM531lycW8zAOG6o9KyTPCnuNPAEfiKMU5JLwiPvhP4TPlprs3BmN5 W7XrutOsN3iYXiPvathHAgaCWw== X-Google-Smtp-Source: ABdhPJyS9F4ENGYjmIXEjls6BZ92TAXa5wPq1KIzlddlnkDZRmM4fxUhzr20ifQ/PO2ulFMHRsKJlg== X-Received: by 2002:a05:600c:3594:: with SMTP id p20mr16548904wmq.52.1624111811778; Sat, 19 Jun 2021 07:10:11 -0700 (PDT) Received: from localhost.localdomain ([83.216.184.132]) by smtp.gmail.com with ESMTPSA id y16sm8379350wrp.51.2021.06.19.07.10.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Jun 2021 07:10:11 -0700 (PDT) From: Paolo Valente To: Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, mariottiluca1@hotmail.it, holger@applied-asynchrony.com, pedroni.pietro.96@gmail.com, Paolo Valente Subject: [PATCH FIXES/IMPROVEMENTS 6/7] block, bfq: check waker only for queues with no in-flight I/O Date: Sat, 19 Jun 2021 16:09:47 +0200 Message-Id: <20210619140948.98712-7-paolo.valente@linaro.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20210619140948.98712-1-paolo.valente@linaro.org> References: <20210619140948.98712-1-paolo.valente@linaro.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org Consider two bfq_queues, say Q1 and Q2, with Q2 empty. If a request of Q1 gets completed shortly before a new request arrives for Q2, then BFQ flags Q1 as a candidate waker for Q2. Yet, the arrival of this new request may have a different cause, in the following case. If also Q2 has requests in flight while waiting for the arrival of a new request, then the completion of its own requests may be the actual cause of the awakening of the process that sends I/O to Q2. So Q1 may be flagged wrongly as a candidate waker. This commit avoids this deceptive flagging, by disabling candidate-waker flagging for Q2, if Q2 has in-flight I/O. Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 7bf073ef9443..a273b2bcea2a 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -1985,14 +1985,18 @@ static void bfq_update_io_intensity(struct bfq_queue *bfqq, u64 now_ns) * Turning back to the detection of a waker queue, a queue Q is deemed * as a waker queue for bfqq if, for three consecutive times, bfqq * happens to become non empty right after a request of Q has been - * completed. In particular, on the first time, Q is tentatively set - * as a candidate waker queue, while on the third consecutive time - * that Q is detected, the field waker_bfqq is set to Q, to confirm - * that Q is a waker queue for bfqq. These detection steps are - * performed only if bfqq has a long think time, so as to make it more - * likely that bfqq's I/O is actually being blocked by a - * synchronization. This last filter, plus the above three-times - * requirement, make false positives less likely. + * completed. In this respect, even if bfqq is empty, we do not check + * for a waker if it still has some in-flight I/O. In fact, in this + * case bfqq is actually still being served by the drive, and may + * receive new I/O on the completion of some of the in-flight + * requests. In particular, on the first time, Q is tentatively set as + * a candidate waker queue, while on the third consecutive time that Q + * is detected, the field waker_bfqq is set to Q, to confirm that Q is + * a waker queue for bfqq. These detection steps are performed only if + * bfqq has a long think time, so as to make it more likely that + * bfqq's I/O is actually being blocked by a synchronization. This + * last filter, plus the above three-times requirement, make false + * positives less likely. * * NOTE * @@ -2018,6 +2022,7 @@ static void bfq_check_waker(struct bfq_data *bfqd, struct bfq_queue *bfqq, if (!bfqd->last_completed_rq_bfqq || bfqd->last_completed_rq_bfqq == bfqq || bfq_bfqq_has_short_ttime(bfqq) || + bfqq->dispatched > 0 || now_ns - bfqd->last_completion >= 4 * NSEC_PER_MSEC || bfqd->last_completed_rq_bfqq == bfqq->waker_bfqq) return; From patchwork Sat Jun 19 14:09:48 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 12333003 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=-18.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham 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 E1EC3C49EA6 for ; Sat, 19 Jun 2021 14:10:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C3E3C61168 for ; Sat, 19 Jun 2021 14:10:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234455AbhFSOMa (ORCPT ); Sat, 19 Jun 2021 10:12:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48282 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234456AbhFSOM0 (ORCPT ); Sat, 19 Jun 2021 10:12:26 -0400 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 57529C0617AF for ; Sat, 19 Jun 2021 07:10:14 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id i94so14109900wri.4 for ; Sat, 19 Jun 2021 07:10:14 -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 :mime-version:content-transfer-encoding; bh=/cCR55PjBCxLhmDeRiMz3VW8PhgOXFh9It9QkVb9bRw=; b=vB4npVjdGxwWpcaRlFlkzRxBN5FdGeJmtFaJf1MtlnLibr9K/cUlP3YkQFTkXwjPnn ddYR6Spaxh4CrqL3qzJ/HYwoMT/S/qITSUcnAUlT1doT68fMFe67BdAg5maPUfftwhgh 0NTC/1oAQOwSNKq0MvqsMGggjTpjaTUGC9u+LXRVdvOVcEnJsVYdQZV9nyugRYTR3UoK DEPmbEns9CkiqeCegRDUU2cwlAz4BxiyL1/UJHCT1l0vhJt6KDVxXqcq6KaVhf1Nq+nD k/oNw1urCNuBl212a9e8oz9d6FmdMp7TcSXme4NTXk32yo2a+MSgRiJOlfNgThicDovk At7A== 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:mime-version:content-transfer-encoding; bh=/cCR55PjBCxLhmDeRiMz3VW8PhgOXFh9It9QkVb9bRw=; b=NoWVjpmJTgiJwZgYSa9ucbSvDNMS2RyizS9yvfRZJ13QsVPqoYiIQLlG0cs13eOQfJ 4/PTT4gRFKGWi8CQWUlY4xc9jsiGWyoA4/cNyfscR67U66kxi28hqzXGtdvIN4ANBtEy H5LETivquONT/a9/Z/Kmi3KcG9fngzQBbHlEtqS25eYUvr5r60LWiLAP4zWSWM1GZsqg +O3lnxYGftbmmxyQF6IbYBA83AH6O/unabrc8xarnR90EjdSqip+uPLkfU4/nIOr0NLa Tt03ey9e3gudposRTGmJNbMjOsTDQXlaQhqo1uNCOoiJm+vW7EtzAiqDuXEr2QdkkcS6 WaXA== X-Gm-Message-State: AOAM533nVYZtUH6daPPWHfYOz8bb5wbccfuOMS5zLdIYbZPmqkvk9GEs k0mN41j7TvRkEDmb9ZTWchq6Qw== X-Google-Smtp-Source: ABdhPJxwoV2PPv/MIS7pll8TpR+IDqS0ZmIHCfRCw1PgHG4SfYvBesOjREgg3VRGRYou2JYS1IvGmg== X-Received: by 2002:adf:fac6:: with SMTP id a6mr18330692wrs.251.1624111812978; Sat, 19 Jun 2021 07:10:12 -0700 (PDT) Received: from localhost.localdomain ([83.216.184.132]) by smtp.gmail.com with ESMTPSA id y16sm8379350wrp.51.2021.06.19.07.10.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Jun 2021 07:10:12 -0700 (PDT) From: Paolo Valente To: Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, mariottiluca1@hotmail.it, holger@applied-asynchrony.com, pedroni.pietro.96@gmail.com, Paolo Valente Subject: [PATCH FIXES/IMPROVEMENTS 7/7] block, bfq: reset waker pointer with shared queues Date: Sat, 19 Jun 2021 16:09:48 +0200 Message-Id: <20210619140948.98712-8-paolo.valente@linaro.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20210619140948.98712-1-paolo.valente@linaro.org> References: <20210619140948.98712-1-paolo.valente@linaro.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org Commit 85686d0dc194 ("block, bfq: keep shared queues out of the waker mechanism") leaves shared bfq_queues out of the waker-detection mechanism. It attains this goal by not updating the pointer last_completed_rq_bfqq, if the last request completed belongs to a shared bfq_queue (so that the pointer will not point to the shared bfq_queue). Yet this has a side effect: the pointer last_completed_rq_bfqq keeps pointing, deceptively, to a bfq_queue that actually is not the last one to have had a request completed. As a consequence, such a bfq_queue may deceptively be considered as a waker of some bfq_queue, even of some shared bfq_queue. To address this issue, reset last_completed_rq_bfqq if the last request completed belongs to a shared queue. Fixes: 85686d0dc194 ("block, bfq: keep shared queues out of the waker mechanism") Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index a273b2bcea2a..fedb0a8fd388 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -6165,11 +6165,13 @@ static void bfq_completed_request(struct bfq_queue *bfqq, struct bfq_data *bfqd) * of other queues. But a false waker will unjustly steal * bandwidth to its supposedly woken queue. So considering * also shared queues in the waking mechanism may cause more - * control troubles than throughput benefits. Then do not set - * last_completed_rq_bfqq to bfqq if bfqq is a shared queue. + * control troubles than throughput benefits. Then reset + * last_completed_rq_bfqq if bfqq is a shared queue. */ if (!bfq_bfqq_coop(bfqq)) bfqd->last_completed_rq_bfqq = bfqq; + else + bfqd->last_completed_rq_bfqq = NULL; /* * If we are waiting to discover whether the request pattern