From patchwork Thu Sep 21 09:04:01 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 113203 Delivered-To: patch@linaro.org Received: by 10.140.106.117 with SMTP id d108csp1771897qgf; Thu, 21 Sep 2017 02:05:28 -0700 (PDT) X-Received: by 10.84.164.104 with SMTP id m37mr4477359plg.332.1505984728803; Thu, 21 Sep 2017 02:05:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1505984728; cv=none; d=google.com; s=arc-20160816; b=UHhatgBgc4S0swHG9IyRC3cNWuw40lQHbcYML4Pg93RZJ9jdyGs54xREUrMjPHL8Wy p+2WVRF2jMFW+Hgzr+ER6UUURAYDPPr+DeHvqtybVsFvFsPzp8gcxruN5gTsuZHapwjx juTLU6DawhvJ3pHq9maNZ7yZCXayVSOP+6gB2qgT5k7NNP3IULcOztn5JHVnk8Y7BK3H 3/LVddylAb9/uF+ZN1JvORMNMn6drE8hwzSncJ7e98Xg7W/FG6VwWlPrVadWYzqRMUXB y8lD/cw6HMdYbejXA97rnET3ttn9Hbzssy949dBUeWMBBucgtSWAKEuH7n5gvXucsRFp V7Jg== 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=EmNGd5CNfE/tiBAagAQeLIcKkVPvWYaVS13dR8lF5a0=; b=zT/xzUz9mYzVRJNusLU+cRP+h2vAvDcIFyvEq4po5DCMIb144BDdCWTf33sNipcb/z BFaOtSE23dJj8mJXmkjKCPzW+q0cAkNnukR2kBYpQ0ORXopqGfK5UfiDyX/xVjTNRUf1 xLInyOoGlxtadesdfWmNU3ey5XLixW4eTFlXyhxAbEA0Wvq8P3cFFVr0Q2ML2OUM7JtO +yfHpJb/Q9hHYnDqRQvIdQ+tEdhMZ0WVU/X9FUavFZaij6H3Dfx/+Yicyj82ceuk2hBp 39X3/AtsfEK9MroyPZ9wZFQl2lkvYmr20aSoMWowGT3b6wKspW1Ol82l/SLUHOHys/cn at1Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Wx8ACFnS; 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 m65si706477pfc.135.2017.09.21.02.05.28; Thu, 21 Sep 2017 02:05:28 -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=Wx8ACFnS; 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 S1752144AbdIUJF0 (ORCPT + 26 others); Thu, 21 Sep 2017 05:05:26 -0400 Received: from mail-wr0-f172.google.com ([209.85.128.172]:48312 "EHLO mail-wr0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751971AbdIUJEm (ORCPT ); Thu, 21 Sep 2017 05:04:42 -0400 Received: by mail-wr0-f172.google.com with SMTP id 108so4027338wra.5 for ; Thu, 21 Sep 2017 02:04:41 -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=EmNGd5CNfE/tiBAagAQeLIcKkVPvWYaVS13dR8lF5a0=; b=Wx8ACFnS36PAh8wBCHRv497iK6n3V35hYxbv2aAqmk0bvU+Jf8FXhEJuYycRUPgV0L tEK/Ipe3kiIp2V/ZTD5YmofRX65b+DDnHXp4YFsWnbrfAfeHoOehROGd6i+NSxuvB/pD IAN58g8LLER2r00UoeBE3UYX9Qt+ugkTjqG6k= 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=EmNGd5CNfE/tiBAagAQeLIcKkVPvWYaVS13dR8lF5a0=; b=LGnSIb4XT0/gnsuFHQrTjrHCLk/k05wl1KGVjDXeB/M1+lCHQ+HlLgK0Qnebdad7g3 /ZeNEjuLV7JskxA6kFKmThD2bCXuG1+DtieozUy9L3rHnCABAXO0K2K0dljIqDp5V8Pb d5ad3MRzhm7pLWN8rOEN3WezwH1Ynm4OIJvheCFa0dSw1eXkOQxVHJAj0thEqtxglxZH 5Hb9FZfNt7+aFjYVbJytVS6aZZMwxsiJ6wW+thTvIMWVPSGyxuw+nw1DqZXuOLwOff9J czPTlzpEsZ87BaaS+Yl0jMbjsVkH5oWvOy5B7lpg2Dgm59cfGp4BUW/GOYULSzudeRMR zuuA== X-Gm-Message-State: AHPjjUg9wtHl/pGCiYB7mWotCJBUAiRCez58XgFUJuuPs+gVCQfTNCzC j5jAVc4Rq8sA9sJh+fL6vJGg3Q== X-Google-Smtp-Source: AOwi7QCGWxHorw/siYRlqpqhi1Wlc2ZOOV5KseDii9l2WNzrmWfILGQ9UZOs48Xba4bbq8hn14wQDg== X-Received: by 10.223.143.105 with SMTP id p96mr1333090wrb.118.1505984680510; Thu, 21 Sep 2017 02:04:40 -0700 (PDT) Received: from localhost.localdomain ([185.14.11.73]) by smtp.gmail.com with ESMTPSA id o59sm804032wrc.45.2017.09.21.02.04.38 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 21 Sep 2017 02:04:39 -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, lee.tibbert@gmail.com, oleksandr@natalenko.name, mirkomontanari91@gmail.com, angeloruocco90@gmail.com, mauro.andreolini@unimore.it, Paolo Valente Subject: [PATCH BUGFIX/IMPROVEMENT 2/4] block, bfq: check and switch back to interactive wr also on queue split Date: Thu, 21 Sep 2017 11:04:01 +0200 Message-Id: <20170921090403.3217-3-paolo.valente@linaro.org> X-Mailer: git-send-email 2.10.0 In-Reply-To: <20170921090403.3217-1-paolo.valente@linaro.org> References: <20170921090403.3217-1-paolo.valente@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org As already explained in the message of commit "block, bfq: fix wrong init of saved start time for weight raising", if a soft real-time weight-raising period happens to be nested in a larger interactive weight-raising period, then BFQ restores the interactive weight raising at the end of the soft real-time weight raising. In particular, BFQ checks whether the latter has ended only on request dispatches. Unfortunately, the above scheme fails to restore interactive weight raising in the following corner case: if a bfq_queue, say Q, 1) Is merged with another bfq_queue while it is in a nested soft real-time weight-raising period. The weight-raising state of Q is then saved, and not considered any longer until a split occurs. 2) Is split from the other bfq_queue(s) at a time instant when its soft real-time weight raising is already finished. On the split, while resuming the previous, soft real-time weight-raised state of the bfq_queue Q, BFQ checks whether the current soft real-time weight-raising period is actually over. If so, BFQ switches weight raising off for Q, *without* checking whether the soft real-time period was actually nested in a non-yet-finished interactive weight-raising period. This commit addresses this issue by adding the above missing check in bfq_queue splits, and restoring interactive weight raising if needed. Signed-off-by: Paolo Valente Tested-by: Angelo Ruocco Tested-by: Mirko Montanari Tested-by: Oleksandr Natalenko --- block/bfq-iosched.c | 87 ++++++++++++++++++++++++++++++----------------------- 1 file changed, 49 insertions(+), 38 deletions(-) -- 2.10.0 diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index c25955c..33b63bc 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -724,6 +724,44 @@ static void bfq_updated_next_req(struct bfq_data *bfqd, } } +static unsigned int bfq_wr_duration(struct bfq_data *bfqd) +{ + u64 dur; + + if (bfqd->bfq_wr_max_time > 0) + return bfqd->bfq_wr_max_time; + + dur = bfqd->RT_prod; + 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. + * + * 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; +} + +/* switch back from soft real-time to interactive weight raising */ +static void switch_back_to_interactive_wr(struct bfq_queue *bfqq, + struct bfq_data *bfqd) +{ + bfqq->wr_coeff = bfqd->bfq_wr_coeff; + bfqq->wr_cur_max_time = bfq_wr_duration(bfqd); + bfqq->last_wr_start_finish = bfqq->wr_start_at_switch_to_srt; +} + static void bfq_bfqq_resume_state(struct bfq_queue *bfqq, struct bfq_data *bfqd, struct bfq_io_cq *bic, bool bfq_already_existing) @@ -750,10 +788,16 @@ bfq_bfqq_resume_state(struct bfq_queue *bfqq, struct bfq_data *bfqd, if (bfqq->wr_coeff > 1 && (bfq_bfqq_in_large_burst(bfqq) || time_is_before_jiffies(bfqq->last_wr_start_finish + bfqq->wr_cur_max_time))) { - bfq_log_bfqq(bfqq->bfqd, bfqq, - "resume state: switching off wr"); - - bfqq->wr_coeff = 1; + if (bfqq->wr_cur_max_time == bfqd->bfq_wr_rt_max_time && + !bfq_bfqq_in_large_burst(bfqq) && + time_is_after_eq_jiffies(bfqq->wr_start_at_switch_to_srt + + bfq_wr_duration(bfqd))) { + switch_back_to_interactive_wr(bfqq, bfqd); + } else { + bfqq->wr_coeff = 1; + bfq_log_bfqq(bfqq->bfqd, bfqq, + "resume state: switching off wr"); + } } /* make sure weight will be updated, however we got here */ @@ -1173,35 +1217,6 @@ static bool bfq_bfqq_update_budg_for_activation(struct bfq_data *bfqd, return wr_or_deserves_wr; } -static unsigned int bfq_wr_duration(struct bfq_data *bfqd) -{ - u64 dur; - - if (bfqd->bfq_wr_max_time > 0) - return bfqd->bfq_wr_max_time; - - dur = bfqd->RT_prod; - 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. - * - * 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 the farthest future time instant according to jiffies * macros. @@ -3501,11 +3516,7 @@ static void bfq_update_wr_data(struct bfq_data *bfqd, struct bfq_queue *bfqq) bfq_wr_duration(bfqd))) bfq_bfqq_end_wr(bfqq); else { - /* switch back to interactive wr */ - bfqq->wr_coeff = bfqd->bfq_wr_coeff; - bfqq->wr_cur_max_time = bfq_wr_duration(bfqd); - bfqq->last_wr_start_finish = - bfqq->wr_start_at_switch_to_srt; + switch_back_to_interactive_wr(bfqq, bfqd); bfqq->entity.prio_changed = 1; } }