From patchwork Fri Jan 22 18:19: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: 12040347 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,URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable 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 E7F0EC433E0 for ; Fri, 22 Jan 2021 19:37:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AFA682076E for ; Fri, 22 Jan 2021 19:37:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729292AbhAVSjC (ORCPT ); Fri, 22 Jan 2021 13:39:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45870 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729769AbhAVSWk (ORCPT ); Fri, 22 Jan 2021 13:22:40 -0500 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 489C1C061793 for ; Fri, 22 Jan 2021 10:20:36 -0800 (PST) Received: by mail-ed1-x52e.google.com with SMTP id b21so7631233edy.6 for ; Fri, 22 Jan 2021 10:20:36 -0800 (PST) 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=kMJc3fvNQabQh6z6D9WSCx7y8czmLn+2gUl4fumpUHU=; b=kw1KtJhYSMS/im4yQwTlK4t79fvvhEJuZFHLnIGO0wREQkpMpOgURKsVOpsQq/Lcz9 mg7Nvhpuo9oVcxocZ4HEWwRnBfb2uegHEkC9+IVCqR1la13k1SBDnAQkkjCVrVrtovGK sDdEfaj7yCxI2PVSc0Tf7R52dDyzqTzd0+LZeym733t+eJR3hN14m9zkzhdefNNcfl0b HVgGuyoWyy7I5Q+ytwcRulLsPS8JST5oAQQjDV+gC8B6EgGxRpyw5ohb7uoXMAIaz/oy VWGdIiMq7YEF5vaTVZOWJUUy4bqVrJsG4ZT6LjT7C0Euxa/nDKCaBodTKzUIfEd9oKZF n0Vg== 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=kMJc3fvNQabQh6z6D9WSCx7y8czmLn+2gUl4fumpUHU=; b=lVZpyCOWtT4lPZ7gITIA1M8d6Y2AeLOMzop+TqyjtzMTMoY6B4IpIzNPSiTQ4nAWRn /2DeDWkykcJHv38wFFoVTkfg5u0TNd5J85MLSLz+B0ES46JdbbST3pMpZ3bg8gBBduvA rMyELqM3ctLiVK2z8R21+egLfMWqyEc1990wzjMDT8tdjYLSr6z3sGTMroKn35Pvkcik MYwIwrDNS67kvCKkz50vZR7cfFDZn0rqWT1RL5cKDkw2fuITv1xBbtzIpoNg6WhBMtyQ ZTaf46i2KCu0NpqRHl5dktogzk9pimZDoxUMAscvJzct2stXd9+gYqZNBmxjrW54WCYX 28Kw== X-Gm-Message-State: AOAM531xgD+qWQq6nuJuA8ZMvlW1mx5Uo+8FcwAhy/Y/wjidF81QRAZ9 cU+jQq33h1KCJ+0jiqM6OroiIA== X-Google-Smtp-Source: ABdhPJwlXNf6RARff5m4Jn8d628AS4mJE8EEUc8+yo0v0fFp5vNff9tinxvvKqC3Hiv9bhepgO2usg== X-Received: by 2002:a50:c34b:: with SMTP id q11mr4248536edb.173.1611339634946; Fri, 22 Jan 2021 10:20:34 -0800 (PST) Received: from localhost.localdomain ([83.216.184.132]) by smtp.gmail.com with ESMTPSA id h16sm6003359eds.21.2021.01.22.10.20.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jan 2021 10:20:34 -0800 (PST) From: Paolo Valente To: Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Paolo Valente , Jan Kara Subject: [PATCH BUGFIX/IMPROVEMENT 1/6] block, bfq: use half slice_idle as a threshold to check short ttime Date: Fri, 22 Jan 2021 19:19:43 +0100 Message-Id: <20210122181948.35660-2-paolo.valente@linaro.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20210122181948.35660-1-paolo.valente@linaro.org> References: <20210122181948.35660-1-paolo.valente@linaro.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org The value of the I/O plugging (idling) timeout is used also as the think-time threshold to decide whether a process has a short think time. In this respect, a good value of this timeout for rotational drives is un the order of several ms. Yet, this is often too long a time interval to be effective as a think-time threshold. This commit mitigates this problem (by a lot, according to tests), by halving the threshold. Tested-by: Jan Kara Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 9e4eb0fc1c16..eb2ca32d5b63 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -5238,12 +5238,13 @@ static void bfq_update_has_short_ttime(struct bfq_data *bfqd, return; /* Think time is infinite if no process is linked to - * bfqq. Otherwise check average think time to - * decide whether to mark as has_short_ttime + * bfqq. Otherwise check average think time to decide whether + * to mark as has_short_ttime. To this goal, compare average + * think time with half the I/O-plugging timeout. */ if (atomic_read(&bic->icq.ioc->active_ref) == 0 || (bfq_sample_valid(bfqq->ttime.ttime_samples) && - bfqq->ttime.ttime_mean > bfqd->bfq_slice_idle)) + bfqq->ttime.ttime_mean > bfqd->bfq_slice_idle>>1)) has_short_ttime = false; state_changed = has_short_ttime != bfq_bfqq_has_short_ttime(bfqq); From patchwork Fri Jan 22 18:19: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: 12040271 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,URIBL_BLOCKED, 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 06B83C433E0 for ; Fri, 22 Jan 2021 18:39:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D3F2623AAC for ; Fri, 22 Jan 2021 18:39:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729446AbhAVSjJ (ORCPT ); Fri, 22 Jan 2021 13:39:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45898 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729780AbhAVSWq (ORCPT ); Fri, 22 Jan 2021 13:22:46 -0500 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 15E17C0617A7 for ; Fri, 22 Jan 2021 10:20:38 -0800 (PST) Received: by mail-ej1-x635.google.com with SMTP id kg20so8518462ejc.4 for ; Fri, 22 Jan 2021 10:20:38 -0800 (PST) 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=sgVql/JRS43dj+W0ld1vynp9FcuzTEJ43layP8Y7y0c=; b=AGf8N892FuK8FQWkL+ZqYoe9BCoOhK1TDiEKUsmlOsmgQzcL67OEdloOPRaNe1hHuz Gmfo4kEsGoEJMsAXjThReYSYkodZ8DjJAdDnSOZet7F294wYEocpiyfHC4htFIx9Wvta G9Fsk0wZDxXsjCWMcMluh8Uix4pMGwhZgd8C002swiz5iiDThchdTUhCszHzqNbPvSiz bUQdaC8CgJmuRTTYQZ8sYatn1g7d3Fpo/SnsfV/LOBP3dlnvojuJV55p5GyEIqiwlEkb NPn2VTF6MNUo8OVcDRNopFrVrgjgTnhMVTGjKkI3d1QSQnjfMnSW5ceznrJpwM47V5d7 MqoQ== 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=sgVql/JRS43dj+W0ld1vynp9FcuzTEJ43layP8Y7y0c=; b=XlHGLMuTJJpIZM0NlAasjVp9DycFpiUJflwEgSw51xkq39hnXqHfGBEznU3zE1+eOA 3xxAHZv0Cs1xhXqWrgsUbIFlKsAUFkW9bvA7xZeE5UmXJVjfyUIUDQNUSAFfAF4QwZoX 1PoWAa6Gh8uikmbiXp5u6l/uTXz74kve4UYxXxw6cr7KhsqjCVwgA6znrNJpi3/b6IfD nqymRXsq7LgsVeBNADhpxbUT5vDoQfr/5TEAFX/wAjsmXCahdsmLrINOWsQrlHbG9g3Y fnmDubmLcX535fs3pdCdiazxT4fLyAr5x63oWbSV7FotxIvDpkwiQnH3bgQmYy8/KuLd vXfQ== X-Gm-Message-State: AOAM532cZPaw28+hqlSMg+p45fUlMf6yA6cDJz4jvUbteGP/R2zStXRl I2AfHn0WCroB2+JH1g8DNrUlCA== X-Google-Smtp-Source: ABdhPJxxlmLudPi8MnmDeE9sqQS2PZnLxn840lWcQdf4uG/dYwL3F2T4ZP7X2Lt2lL+191Rsk3nR7A== X-Received: by 2002:a17:906:478a:: with SMTP id cw10mr3734136ejc.533.1611339636708; Fri, 22 Jan 2021 10:20:36 -0800 (PST) Received: from localhost.localdomain ([83.216.184.132]) by smtp.gmail.com with ESMTPSA id h16sm6003359eds.21.2021.01.22.10.20.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jan 2021 10:20:36 -0800 (PST) From: Paolo Valente To: Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Jia Cheng Hu , Jan Kara , Paolo Valente Subject: [PATCH BUGFIX/IMPROVEMENT 2/6] block, bfq: set next_rq to waker_bfqq->next_rq in waker injection Date: Fri, 22 Jan 2021 19:19:44 +0100 Message-Id: <20210122181948.35660-3-paolo.valente@linaro.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20210122181948.35660-1-paolo.valente@linaro.org> References: <20210122181948.35660-1-paolo.valente@linaro.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org From: Jia Cheng Hu Since commit c5089591c3ba ("block, bfq: detect wakers and unconditionally inject their I/O"), when the in-service bfq_queue, say Q, is temporarily empty, BFQ checks whether there are I/O requests to inject (also) from the waker bfq_queue for Q. To this goal, the value pointed by bfqq->waker_bfqq->next_rq must be controlled. However, the current implementation mistakenly looks at bfqq->next_rq, which instead points to the next request of the currently served queue. This mistake evidently causes losses of throughput in scenarios with waker bfq_queues. This commit corrects this mistake. Fixes: c5089591c3ba ("block, bfq: detect wakers and unconditionally inject their I/O") Signed-off-by: Jia Cheng Hu Signed-off-by: Jan Kara Signed-off-by: Paolo Valente --- 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 eb2ca32d5b63..fdc5e163b2fe 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -4499,7 +4499,7 @@ static struct bfq_queue *bfq_select_queue(struct bfq_data *bfqd) bfqq = bfqq->bic->bfqq[0]; else if (bfq_bfqq_has_waker(bfqq) && bfq_bfqq_busy(bfqq->waker_bfqq) && - bfqq->next_rq && + bfqq->waker_bfqq->next_rq && bfq_serv_to_charge(bfqq->waker_bfqq->next_rq, bfqq->waker_bfqq) <= bfq_bfqq_budget_left(bfqq->waker_bfqq) From patchwork Fri Jan 22 18:19: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: 12040345 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,URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable 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 5B7A7C43142 for ; Fri, 22 Jan 2021 19:36:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EEAC823B00 for ; Fri, 22 Jan 2021 19:36:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728844AbhAVSjT (ORCPT ); Fri, 22 Jan 2021 13:39:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45950 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729786AbhAVSXD (ORCPT ); Fri, 22 Jan 2021 13:23:03 -0500 Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 77DC0C0617AA for ; Fri, 22 Jan 2021 10:20:39 -0800 (PST) Received: by mail-ej1-x62a.google.com with SMTP id r12so8960062ejb.9 for ; Fri, 22 Jan 2021 10:20:39 -0800 (PST) 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=9J+BrlLYgTspJD9ye4jQWIk1CnW/3Fa8FFYzOeIfBjg=; b=pNsesT89U7y5KJ1pEZlTSDCIUB5uvizLU78Mu0wTiEKOO6D/10eVKYuCXomHEVIoF1 uUJBOkyDvdVYAkJxpIDPAbraxpqDhBjCb3We1hpwVHhnm9pxK7YLrAnL2iJrRhrDdgnc s/uSwg4i//AxxRlFCtZ8B1u1eZC6WxDLPAvQOrJErEpEwdS561izyrWaMWQsqPaNZDPy y6LiZyvwSyCL58UYszo6WQrXpvjyyEkV6G4/YcX049kuaJ78b4FotKTG33jnjbXjrs52 1rEF6piabrfbjVRBjQ/mkxavp7GALCttEbLKv/dB3uan96JCtAEZutKrMpbfLDeQeBJe gPyg== 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=9J+BrlLYgTspJD9ye4jQWIk1CnW/3Fa8FFYzOeIfBjg=; b=eePoq3nhlzHyrcwk0uDPmvAyRM6bmLym0sFZwRvAGznmsPMMAn2xODQPypq31AUzJ8 sA4gi2vfauOFnuMqB02oIClZwNZG6zvop5C3C2WWROrHV+qiEepWdBq6V60E+PTfdWBE nllxcc83Po5qgFgq4IekrcwVumWyGbjgOkZaeJpB3dm7uoXNe6cm6ILagGP2BiOYDXtN 8Nbt4+NtcSsDVPxckOWeMIiNQf/dypRZVQgQMHVfrEpfADboxyiJAiqJIvkWbB/w6nRV H9jnsAyR1NttZgEAAeZXAXcVpiqNNg2JVQXn5q3WfaI/YJut2zE2ebao8MzkCc3XNcja 6ydQ== X-Gm-Message-State: AOAM5322Cxu3zh3Znfak7FwPR2yYGoOpycv8iQMIHeW0J2RFEWp0DoWP u+gqePoq3HTxzvEqPniBYPflRw== X-Google-Smtp-Source: ABdhPJyqm3+gKiCprsqFB+RUq/U8eR1CKgZSuBsW/tlTEJqKlqoa9pAtScGwg5GqO/PqylyRRvoGiQ== X-Received: by 2002:a17:906:1958:: with SMTP id b24mr3742722eje.263.1611339638190; Fri, 22 Jan 2021 10:20:38 -0800 (PST) Received: from localhost.localdomain ([83.216.184.132]) by smtp.gmail.com with ESMTPSA id h16sm6003359eds.21.2021.01.22.10.20.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jan 2021 10:20:37 -0800 (PST) From: Paolo Valente To: Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Paolo Valente , Jan Kara Subject: [PATCH BUGFIX/IMPROVEMENT 3/6] block, bfq: increase time window for waker detection Date: Fri, 22 Jan 2021 19:19:45 +0100 Message-Id: <20210122181948.35660-4-paolo.valente@linaro.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20210122181948.35660-1-paolo.valente@linaro.org> References: <20210122181948.35660-1-paolo.valente@linaro.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org Tests on slower machines showed current window to be way too small. This commit increases it. Tested-by: Jan Kara Signed-off-by: Paolo Valente --- 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 fdc5e163b2fe..43e2c39cf7b5 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -1931,7 +1931,7 @@ static void bfq_add_request(struct request *rq) if (bfqd->last_completed_rq_bfqq && !bfq_bfqq_has_short_ttime(bfqq) && ktime_get_ns() - bfqd->last_completion < - 200 * NSEC_PER_USEC) { + 4 * NSEC_PER_MSEC) { if (bfqd->last_completed_rq_bfqq != bfqq && bfqd->last_completed_rq_bfqq != bfqq->waker_bfqq) { From patchwork Fri Jan 22 18:19:46 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 12040249 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,URIBL_BLOCKED, 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 59851C433E0 for ; Fri, 22 Jan 2021 18:32:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 212DE23AAC for ; Fri, 22 Jan 2021 18:32:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728965AbhAVScR (ORCPT ); Fri, 22 Jan 2021 13:32:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46170 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729971AbhAVSYB (ORCPT ); Fri, 22 Jan 2021 13:24:01 -0500 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C95E2C061352 for ; Fri, 22 Jan 2021 10:20:40 -0800 (PST) Received: by mail-ej1-x632.google.com with SMTP id g12so8996427ejf.8 for ; Fri, 22 Jan 2021 10:20:40 -0800 (PST) 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=p+AQjI2U+yUBUU1UOk70xCwlbSNDVtJV8+/awv6Dy3Q=; b=V4DkIqgNIUIMmsH+yc3SlpEZgRr19v1NIqn67hxQj1/aTppMKXCa2++83nZgto3fzp UEpy6hK97Snnp0msOrhNnhyIb4d8K3eS+CaqBQ5UgNhhbuSGJpL+TNtKEEphNWjLAbaU hOMGOI1yDJJTRh5sc8UivSLVmAQn4FXvLgNrEGYdvhM47pUf6GbRS/LiVibq1TWej+QY pU7TrAvta4eyLMyY3MftWefyuR3khOcmvm8lXFYsax4+/tMDGDOfPEw/qpJQHo12Yq00 ZS/FR8XM4rihUZOcGN3W5UugLOw+b557adMUoKecDAkg8CPlWT9JkhM/xB97FfmqinDo U9Eg== 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=p+AQjI2U+yUBUU1UOk70xCwlbSNDVtJV8+/awv6Dy3Q=; b=uod4ByuhowGLrQ7oh+pD0gv/bAMMptX3whDxYhdJTkJP/2cYp16rSO4eDMSt/6uonB +pY+9mnGj3/iSAMVOSYxaA63jPa0O01PsBIPCAll7bnCTZd/HODYpE5URuGGFU8fER9x 89ROmoXHehteCDfe6L1otmDXDGEg3isaV6+N9fhz0z/kge2xD4MvbOBNchu7a/OpSE5j OIk8/PiSpCqyZG2VDzViuBzuh1621yn+k48LBZzhPnzQnY2WU3tjT3K9GiND7+pakXnC RPsrMeJ8woDM44rDgwf5VB8o+/cfMqYnjp1BB8MNm1jL9BtYxNcgnI3aSUWOiXaqIMb6 YjKQ== X-Gm-Message-State: AOAM530abgB8z7Huoqu2vMJr1GyXVek3eUc3pppkkId8cT/iQM06lVkq sMOkbwevP7kl/+sEnTKvOi7ZOg== X-Google-Smtp-Source: ABdhPJy6LPrplZSe7WQBdHSUg6UYki3rzLptrGfgDNJw04ZfImNmWt4qs7xjWf9VO391VfV81YvB/w== X-Received: by 2002:a17:907:1b10:: with SMTP id mp16mr3889169ejc.482.1611339639461; Fri, 22 Jan 2021 10:20:39 -0800 (PST) Received: from localhost.localdomain ([83.216.184.132]) by smtp.gmail.com with ESMTPSA id h16sm6003359eds.21.2021.01.22.10.20.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jan 2021 10:20:38 -0800 (PST) From: Paolo Valente To: Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Paolo Valente , Jan Kara Subject: [PATCH BUGFIX/IMPROVEMENT 4/6] block, bfq: do not raise non-default weights Date: Fri, 22 Jan 2021 19:19:46 +0100 Message-Id: <20210122181948.35660-5-paolo.valente@linaro.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20210122181948.35660-1-paolo.valente@linaro.org> References: <20210122181948.35660-1-paolo.valente@linaro.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org BFQ heuristics try to detect interactive I/O, and raise the weight of the queues containing such an I/O. Yet, if also the user changes the weight of a queue (i.e., the user changes the ioprio of the process associated with that queue), then it is most likely better to prevent BFQ heuristics from silently changing the same weight. Tested-by: Jan Kara Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 43e2c39cf7b5..161badb744d6 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -1671,15 +1671,19 @@ static void bfq_bfqq_handle_idle_busy_switch(struct bfq_data *bfqd, * - it is sync, * - it does not belong to a large burst, * - it has been idle for enough time or is soft real-time, - * - is linked to a bfq_io_cq (it is not shared in any sense). + * - is linked to a bfq_io_cq (it is not shared in any sense), + * - has a default weight (otherwise we assume the user wanted + * to control its weight explicitly) */ in_burst = bfq_bfqq_in_large_burst(bfqq); soft_rt = bfqd->bfq_wr_max_softrt_rate > 0 && !BFQQ_TOTALLY_SEEKY(bfqq) && !in_burst && time_is_before_jiffies(bfqq->soft_rt_next_start) && - bfqq->dispatched == 0; - *interactive = !in_burst && idle_for_long_time; + bfqq->dispatched == 0 && + bfqq->entity.new_weight == 40; + *interactive = !in_burst && idle_for_long_time && + bfqq->entity.new_weight == 40; wr_or_deserves_wr = bfqd->low_latency && (bfqq->wr_coeff > 1 || (bfq_bfqq_sync(bfqq) && From patchwork Fri Jan 22 18:19: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: 12040247 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,URIBL_BLOCKED, 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 71FFDC433E0 for ; Fri, 22 Jan 2021 18:32:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 279B623AAC for ; Fri, 22 Jan 2021 18:32:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728757AbhAVScQ (ORCPT ); Fri, 22 Jan 2021 13:32:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46184 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729981AbhAVSYF (ORCPT ); Fri, 22 Jan 2021 13:24:05 -0500 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D51C6C061353 for ; Fri, 22 Jan 2021 10:20:42 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id a10so8986727ejg.10 for ; Fri, 22 Jan 2021 10:20:42 -0800 (PST) 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=0ync7PZ48gx4UVZHAI7K02vmsl5qLTj/68LiBQ/q3fY=; b=WHKfG20W1NGjqkxbfsmPZbXVg+hViuMYnDXAU3Db0epIqKa31itA4Px7dLa/a9ZraV jL3rOkuREAsWxTgaeEIHnsjLRb0IZIZq0qgFNJYpQMBHwFdtGvSmcbEAMCcPFOWHQtJu FsjBn1w439MPo3jxdbUfiR2XRP0+KUBfo6Ojv/Z1USQYZkU0p8bToG/89tCGtu8w/BJo sVWmFMGHLJQoV4WytiOLbWl5u/A79aeuuMcEDjlpQQnqwq+wgix47u19EbA4r2eIEnIC Xpd/ZA3yBZZCE1DJr4b+W1cn0RURLy7SAqyGueDhSwi0xzp5fK8F8qm+cvQ5B8vikDjN Uv7w== 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=0ync7PZ48gx4UVZHAI7K02vmsl5qLTj/68LiBQ/q3fY=; b=uMAX1a1YA3KAEaLedn1DpW61xXelTovlMwxFOOWagc8RRncgnnA/mzu31ofvBSwul2 kMY3gGQun7us5RjKKgAn52bhXmzxRo/iQk1aGO3z/0e3XfnM1shfo1tHJoAvjQ4wj2Be nqp1ZIfbnyzwBuX7l109YfWUrAdt84kvHZo5i8UPqtFzNYHzn5KA3ai7ebcsywB2wYOV SQq81f4+XkzR/QWmok+yeTh/SUETqKY+BIdJ5Ch3iFzEIurxTbAxjm8MxV9Ox4gM0TcW 6drWzZF8El8lLl3al51I73fe7Ydoftau85ltunfw8ZdDNReyUNPt0loBMD29uWWbgWCE SqqA== X-Gm-Message-State: AOAM5309cZoLruax/mvtH9Zdqlc8GGN1YeRmFRYU/jwjlAP+Wvk9DOhq O8Gn6wPkkHrUfJ0aXQ17LaLTrA== X-Google-Smtp-Source: ABdhPJxq4Z+S+aEJXgZVIgei4gpelzO0H045ROe5jVkLKD8AmH04Yk3ARPXBkmynCIBIL6Gn6imcFw== X-Received: by 2002:a17:907:d04:: with SMTP id gn4mr2621650ejc.126.1611339641511; Fri, 22 Jan 2021 10:20:41 -0800 (PST) Received: from localhost.localdomain ([83.216.184.132]) by smtp.gmail.com with ESMTPSA id h16sm6003359eds.21.2021.01.22.10.20.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jan 2021 10:20:40 -0800 (PST) From: Paolo Valente To: Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Paolo Valente , Jan Kara Subject: [PATCH BUGFIX/IMPROVEMENT 5/6] block, bfq: avoid spurious switches to soft_rt of interactive queues Date: Fri, 22 Jan 2021 19:19:47 +0100 Message-Id: <20210122181948.35660-6-paolo.valente@linaro.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20210122181948.35660-1-paolo.valente@linaro.org> References: <20210122181948.35660-1-paolo.valente@linaro.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org BFQ tags some bfq_queues as interactive or soft_rt if it deems that these bfq_queues contain the I/O of, respectively, interactive or soft real-time applications. BFQ privileges both these special types of bfq_queues over normal bfq_queues. To privilege a bfq_queue, BFQ mainly raises the weight of the bfq_queue. In particular, soft_rt bfq_queues get a higher weight than interactive bfq_queues. A bfq_queue may turn from interactive to soft_rt. And this leads to a tricky issue. Soft real-time applications usually start with an I/O-bound, interactive phase, in which they load themselves into main memory. BFQ correctly detects this phase, and keeps the bfq_queues associated with the application in interactive mode for a while. Problems arise when the I/O pattern of the application finally switches to soft real-time. One of the conditions for a bfq_queue to be deemed as soft_rt is that the bfq_queue does not consume too much bandwidth. But the bfq_queues associated with a soft real-time application consume as much bandwidth as they can in the loading phase of the application. So, after the application becomes truly soft real-time, a lot of time should pass before the average bandwidth consumed by its bfq_queues finally drops to a value acceptable for soft_rt bfq_queues. As a consequence, there might be a time gap during which the application is not privileged at all, because its bfq_queues are not interactive any longer, but cannot be deemed as soft_rt yet. To avoid this problem, BFQ pretends that an interactive bfq_queue consumes zero bandwidth, and allows an interactive bfq_queue to switch to soft_rt. Yet, this fake zero-bandwidth consumption easily causes the bfq_queue to often switch to soft_rt deceptively, during its loading phase. As in soft_rt mode, the bfq_queue gets its bandwidth correctly computed, and therefore soon switches back to interactive. Then it switches again to soft_rt, and so on. These spurious fluctuations usually cause losses of throughput, because they deceive BFQ's mechanisms for boosting throughput (injection, I/O-plugging avoidance, ...). This commit addresses this issue as follows: 1) It does compute actual bandwidth consumption also for interactive bfq_queues. This avoids the above false positives. 2) When a bfq_queue switches from interactive to normal mode, the consumed bandwidth is reset (forgotten). This allows the bfq_queue to enjoy soft_rt very quickly. In particular, two alternatives are possible in this switch: - the bfq_queue still has backlog, and therefore there is a budget already scheduled to serve the bfq_queue; in this case, the scheduling of the current budget of the bfq_queue is not hindered, because only the scheduling of the next budget will be affected by the weight drop. After that, if the bfq_queue is actually in a soft_rt phase, and becomes empty during the service of its current budget, which is the natural behavior of a soft_rt bfq_queue, then the bfq_queue will be considered as soft_rt when its next I/O arrives. If, in contrast, the bfq_queue remains constantly non-empty, then its next budget will be scheduled with a low weight, which is the natural treatment for an I/O-bound (non soft_rt) bfq_queue. - the bfq_queue is empty; in this case, the bfq_queue may be considered unjustly soft_rt when its new I/O arrives. Yet the problem is now much smaller than before, because it is unlikely that more than one spurious fluctuation occurs. Tested-by: Jan Kara Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 57 +++++++++++++++++++++++++++++---------------- 1 file changed, 37 insertions(+), 20 deletions(-) diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 161badb744d6..003c96fa01ad 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -2356,6 +2356,24 @@ static void bfq_requests_merged(struct request_queue *q, struct request *rq, /* Must be called with bfqq != NULL */ static void bfq_bfqq_end_wr(struct bfq_queue *bfqq) { + /* + * If bfqq has been enjoying interactive weight-raising, then + * reset soft_rt_next_start. We do it for the following + * reason. bfqq may have been conveying the I/O needed to load + * a soft real-time application. Such an application actually + * exhibits a soft real-time I/O pattern after it finishes + * loading, and finally starts doing its job. But, if bfqq has + * been receiving a lot of bandwidth so far (likely to happen + * on a fast device), then soft_rt_next_start now contains a + * high value that. So, without this reset, bfqq would be + * prevented from being possibly considered as soft_rt for a + * very long time. + */ + + if (bfqq->wr_cur_max_time != + bfqq->bfqd->bfq_wr_rt_max_time) + bfqq->soft_rt_next_start = jiffies; + if (bfq_bfqq_busy(bfqq)) bfqq->bfqd->wr_busy_queues--; bfqq->wr_coeff = 1; @@ -3956,30 +3974,15 @@ void bfq_bfqq_expire(struct bfq_data *bfqd, * If we get here, and there are no outstanding * requests, then the request pattern is isochronous * (see the comments on the function - * bfq_bfqq_softrt_next_start()). Thus we can compute - * soft_rt_next_start. And we do it, unless bfqq is in - * interactive weight raising. We do not do it in the - * latter subcase, for the following reason. bfqq may - * be conveying the I/O needed to load a soft - * real-time application. Such an application will - * actually exhibit a soft real-time I/O pattern after - * it finally starts doing its job. But, if - * soft_rt_next_start is computed here for an - * interactive bfqq, and bfqq had received a lot of - * service before remaining with no outstanding - * request (likely to happen on a fast device), then - * soft_rt_next_start would be assigned such a high - * value that, for a very long time, bfqq would be - * prevented from being possibly considered as soft - * real time. + * bfq_bfqq_softrt_next_start()). Therefore we can + * compute soft_rt_next_start. * * If, instead, the queue still has outstanding * requests, then we have to wait for the completion * of all the outstanding requests to discover whether * the request pattern is actually isochronous. */ - if (bfqq->dispatched == 0 && - bfqq->wr_coeff != bfqd->bfq_wr_coeff) + if (bfqq->dispatched == 0) bfqq->soft_rt_next_start = bfq_bfqq_softrt_next_start(bfqd, bfqq); else if (bfqq->dispatched > 0) { @@ -4563,9 +4566,21 @@ static void bfq_update_wr_data(struct bfq_data *bfqd, struct bfq_queue *bfqq) bfqq->wr_cur_max_time)) { if (bfqq->wr_cur_max_time != bfqd->bfq_wr_rt_max_time || time_is_before_jiffies(bfqq->wr_start_at_switch_to_srt + - bfq_wr_duration(bfqd))) + bfq_wr_duration(bfqd))) { + /* + * Either in interactive weight + * raising, or in soft_rt weight + * raising with the + * interactive-weight-raising period + * elapsed (so no switch back to + * interactive weight raising). + */ bfq_bfqq_end_wr(bfqq); - else { + } else { /* + * soft_rt finishing while still in + * interactive period, switch back to + * interactive weight raising + */ switch_back_to_interactive_wr(bfqq, bfqd); bfqq->entity.prio_changed = 1; } @@ -5016,6 +5031,8 @@ bfq_set_next_ioprio_data(struct bfq_queue *bfqq, struct bfq_io_cq *bic) } bfqq->entity.new_weight = bfq_ioprio_to_weight(bfqq->new_ioprio); + bfq_log_bfqq(bfqd, bfqq, "new_ioprio %d new_weight %d", + bfqq->new_ioprio, bfqq->entity.new_weight); bfqq->entity.prio_changed = 1; } From patchwork Fri Jan 22 18:19: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: 12040245 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,URIBL_BLOCKED, 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 11086C433E0 for ; Fri, 22 Jan 2021 18:26:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D7163233FA for ; Fri, 22 Jan 2021 18:26:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729275AbhAVS0X (ORCPT ); Fri, 22 Jan 2021 13:26:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46406 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729114AbhAVSZG (ORCPT ); Fri, 22 Jan 2021 13:25:06 -0500 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 45045C06121C for ; Fri, 22 Jan 2021 10:20:44 -0800 (PST) Received: by mail-ej1-x633.google.com with SMTP id w1so8951000ejf.11 for ; Fri, 22 Jan 2021 10:20:44 -0800 (PST) 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=/yCgqi7f2roNb4s5kP0Oap9h52ux6bvqmo8LLvwwwI4=; b=X3QmT+eTFnpj46VwDNdj5PJQHwwQyi8jw+LjbgnrE+X03Us0A/Dik7iimtDDTeFGtk Z/1NV+K8YtlgtjxnUB7jgyE1qB0i+lo1xQDmtQ0qGe+8NphATxuZr9HfhejcFoCJyeMh H9G4Aiwh0CxScKK1RMyvwRkwrUyVoKTnkxddvBlcLtWuA1qqNFHJJtjtIxx7z8rEBO+S Fhl1Je1AHsB3t/gcSnHgkEnaXNs735rQBn2fnxZB0fz+m5j0TUp+djnxd0oVpXKZuyEx XdvMiURlJJoeZxzcAIDYOX/Fxpr1Z0wKA2CIaK28sumQ+Dsyg38CgBLTw0tCfLt3ksTS Kxfw== 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=/yCgqi7f2roNb4s5kP0Oap9h52ux6bvqmo8LLvwwwI4=; b=VmFY85eWcMB5kdocWx7Uqp9NDKFhighEX1e5CEUoiDfHBtmk/7ypCG51/BvJO4C2tT OjtpZVP6meph+QHSGhxPFZYRETnYMGglTxaD/wVEND7cEXrrO4G+z75KhuUaEPSvjcz6 ghkqmXupZszkrxIJMbtcRL6R4Eb25+3gMNTdKLUIZRMmR4YgCoVqQ7seMjd5E6j5Qjgw 9rlbOhC7+TNn1yaa8mIcExceh4shHFQ4b06JBJsaqJMby9leezfLL571amiPMnoqTEUy erohz+DAv7Us7p6C2o5fNSO5uesjUc/+pAk4h5oZ4nZv66gNZytbdjtnDJqt4KgFlElu K5yA== X-Gm-Message-State: AOAM531CTzj/ZO6e7C2GSXk8kt4Qgd4PfJFVHaaAuywx9DXUYi5N8TeG M4Gr5XgeqU6hHyG/fZ2CQZO9CQ== X-Google-Smtp-Source: ABdhPJxXPmVqwY1t4uXcCkP9lVxbR/zI4nKGts8fMBhxsSI/fR63+SvIJKhuF88EgHN37UnKRqKZ4A== X-Received: by 2002:a17:906:29d4:: with SMTP id y20mr3859274eje.294.1611339642885; Fri, 22 Jan 2021 10:20:42 -0800 (PST) Received: from localhost.localdomain ([83.216.184.132]) by smtp.gmail.com with ESMTPSA id h16sm6003359eds.21.2021.01.22.10.20.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jan 2021 10:20:42 -0800 (PST) From: Paolo Valente To: Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Paolo Valente , Jan Kara Subject: [PATCH BUGFIX/IMPROVEMENT 6/6] block, bfq: do not expire a queue when it is the only busy one Date: Fri, 22 Jan 2021 19:19:48 +0100 Message-Id: <20210122181948.35660-7-paolo.valente@linaro.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20210122181948.35660-1-paolo.valente@linaro.org> References: <20210122181948.35660-1-paolo.valente@linaro.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org This commits preserves I/O-dispatch plugging for a special symmetric case that may suddenly turn into asymmetric: the case where only one bfq_queue, say bfqq, is busy. In this case, not expiring bfqq does not cause any harm to any other queues in terms of service guarantees. In contrast, it avoids the following unlucky sequence of events: (1) bfqq is expired, (2) a new queue with a lower weight than bfqq becomes busy (or more queues), (3) the new queue is served until a new request arrives for bfqq, (4) when bfqq is finally served, there are so many requests of the new queue in the drive that the pending requests for bfqq take a lot of time to be served. In particular, event (2) may case even already dispatched requests of bfqq to be delayed, inside the drive. So, to avoid this series of events, the scenario is preventively declared as asymmetric also if bfqq is the only busy queues. By doing so, I/O-dispatch plugging is performed for bfqq. Tested-by: Jan Kara Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 003c96fa01ad..c045613ce927 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -3464,20 +3464,38 @@ static void bfq_dispatch_remove(struct request_queue *q, struct request *rq) * order until all the requests already queued in the device have been * served. The last sub-condition commented above somewhat mitigates * this problem for weight-raised queues. + * + * However, as an additional mitigation for this problem, we preserve + * plugging for a special symmetric case that may suddenly turn into + * asymmetric: the case where only bfqq is busy. In this case, not + * expiring bfqq does not cause any harm to any other queues in terms + * of service guarantees. In contrast, it avoids the following unlucky + * sequence of events: (1) bfqq is expired, (2) a new queue with a + * lower weight than bfqq becomes busy (or more queues), (3) the new + * queue is served until a new request arrives for bfqq, (4) when bfqq + * is finally served, there are so many requests of the new queue in + * the drive that the pending requests for bfqq take a lot of time to + * be served. In particular, event (2) may case even already + * dispatched requests of bfqq to be delayed, inside the drive. So, to + * avoid this series of events, the scenario is preventively declared + * as asymmetric also if bfqq is the only busy queues */ static bool idling_needed_for_service_guarantees(struct bfq_data *bfqd, struct bfq_queue *bfqq) { + int tot_busy_queues = bfq_tot_busy_queues(bfqd); + /* No point in idling for bfqq if it won't get requests any longer */ if (unlikely(!bfqq_process_refs(bfqq))) return false; return (bfqq->wr_coeff > 1 && (bfqd->wr_busy_queues < - bfq_tot_busy_queues(bfqd) || + tot_busy_queues || bfqd->rq_in_driver >= bfqq->dispatched + 4)) || - bfq_asymmetric_scenario(bfqd, bfqq); + bfq_asymmetric_scenario(bfqd, bfqq) || + tot_busy_queues == 1; } static bool __bfq_bfqq_expire(struct bfq_data *bfqd, struct bfq_queue *bfqq,