From patchwork Thu Sep 21 09:04:02 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 113204 Delivered-To: patch@linaro.org Received: by 10.140.106.117 with SMTP id d108csp1773046qgf; Thu, 21 Sep 2017 02:06:38 -0700 (PDT) X-Received: by 10.98.62.131 with SMTP id y3mr4895788pfj.178.1505984689900; Thu, 21 Sep 2017 02:04:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1505984689; cv=none; d=google.com; s=arc-20160816; b=uns/44LyWt2eDBKNlWSUjl5HVCbZRUVvOehF2M6nQZZPIoKun6Oo01bA3mRd+yWcd6 PUO9yQDxwVzsetovHrDSqRBGo8YZ/estMxOVy5GJQug1p8xUpmdfXIoFCiN010rSxKJh if72n8qPKjdrb++reA7s8jdjX9FKzHxTs+GMYg2seAVPSyc53jb4L8wbmXfScWYxMcSF oM/gGedKIEhxg0h0CkOtC5LSJVftcl5/8qU4C5QL3ipDYqYGu/I5DNgIlwZsZS4SHXWF leEEpftBp4Z5sJw1y3KnyXtcL8KCiXTgRaoq+TOFHk/xyrRiv86wraNma4K/SWB5Qvhv Duww== 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=qBgG8pYDmGg7nnRRdHEvMXAdPItOwxKitC8PRYUEDz0=; b=PWfDzpgjZt/GFmqim8L944T7G7bKWkN8ffX+D2oh8dX8n7949FvgVkBz0y3PGYmb5H +JSh9+QfAbQT3+5NRUdguX41bhZF1fxtM1dvCNkDVAaSWHjAysEMb+SqFs+Zp7/iH5j9 zpdtSgC7nW0kqswXe3UgQX73+lsXc14lgeXWFycPAma9C5/6h97Cnu+GDuQFRWPZxPbh G5k1o7rCuXwb748cC7oOcgjL2MoJsNlDnfkX/JU+Hnbc4+Z9KdSCsT2QmqqNqzWr/W01 Ee6QtDQzZRkUG4zXuw/NwBZEtt1XR5vUqlSVvmqFSnrIw0cjkL5Fcp/2M8uFtz3pV91k SAyA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=CO04yxwg; 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 l2si791530pln.441.2017.09.21.02.04.49; Thu, 21 Sep 2017 02:04:49 -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=CO04yxwg; 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 S1752084AbdIUJEr (ORCPT + 26 others); Thu, 21 Sep 2017 05:04:47 -0400 Received: from mail-wm0-f54.google.com ([74.125.82.54]:49467 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752039AbdIUJEn (ORCPT ); Thu, 21 Sep 2017 05:04:43 -0400 Received: by mail-wm0-f54.google.com with SMTP id e71so13547187wmg.4 for ; Thu, 21 Sep 2017 02:04:43 -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=qBgG8pYDmGg7nnRRdHEvMXAdPItOwxKitC8PRYUEDz0=; b=CO04yxwgL140tpLiqeRx2DWl3PFpP/4Ph1sNVne+XOE2Lwz3jgHHtjpUYIPGZDmZZW 3s93/aZDJXe+oxEb+QTeOSprxKqLvsWd6iRRXjQ+MPwlD6Sz77Mzr4rOFpB/gNj/2SET R5clPyh//0fEotdiawbCuWLiKbQfJXGPlEBs4= 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=qBgG8pYDmGg7nnRRdHEvMXAdPItOwxKitC8PRYUEDz0=; b=fKcftzEaQtqDFMKxgTKQ2R9vB77lpyHsJKWeGOtR7/1e7uZL1d6U/XQbqFUGt72aXU 9LOam0bhlUAuJjSfph47lbz8nbfpwfkWgl8vQ0tg1F/NvMxqJrviWLr/RexkmOywQN8y TNSNVmyAdKh8We2sHqSjXtnX28oIBy8CPZQTw7tfUKexT5Iuv60m0nzN46VsLg1qs1Tr JaQ1odQEnggCCHTKIrMg22buwKAaR+xXMkXYHkXc9yViXaG5KoV6BkgjUgkEY2wLHkGA 7+oUND6NTS94c1SneCIi1j047r4fr2l+MAM+CnL2ycb0dv4f4/f4E4rd7H1jlQBqBAP5 sjKw== X-Gm-Message-State: AHPjjUig31fg5Jj+UgoBhN/vQMFBnHO6M6DuxjsylQqqnDrLYyxIdBwv Oik/xbE50zpl9bRzvfyW6p0tqA== X-Google-Smtp-Source: AOwi7QDkQd6zQyLigWxfNLOwRzBBxpZaHu7q2REqgjphAEMCe6OGDJyZBBTI2PZOoLKF8zGtVXT49g== X-Received: by 10.28.130.131 with SMTP id e125mr345276wmd.125.1505984682406; Thu, 21 Sep 2017 02:04:42 -0700 (PDT) Received: from localhost.localdomain ([185.14.11.73]) by smtp.gmail.com with ESMTPSA id o59sm804032wrc.45.2017.09.21.02.04.40 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 21 Sep 2017 02:04:41 -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 3/4] block, bfq: let early-merged queues be weight-raised on split too Date: Thu, 21 Sep 2017 11:04:02 +0200 Message-Id: <20170921090403.3217-4-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 A just-created bfq_queue, say Q, may happen to be merged with another bfq_queue on the very first invocation of the function __bfq_insert_request. In such a case, even if Q would clearly deserve interactive weight raising (as it has just been created), the function bfq_add_request does not make it to be invoked for Q, and thus to activate weight raising for Q. As a consequence, when the state of Q is saved for a possible future restore, after a split of Q from the other bfq_queue(s), such a state happens to be (unjustly) non-weight-raised. Then the bfq_queue will not enjoy any weight raising on the split, even if should still be in an interactive weight-raising period when the split occurs. This commit solves this problem as follows, for a just-created bfq_queue that is being early-merged: it stores directly, in the saved state of the bfq_queue, the weight-raising state that would have been assigned to the bfq_queue if not early-merged. Signed-off-by: Paolo Valente Tested-by: Angelo Ruocco Tested-by: Mirko Montanari Tested-by: Oleksandr Natalenko --- block/bfq-iosched.c | 28 +++++++++++++++++++++++----- 1 file changed, 23 insertions(+), 5 deletions(-) -- 2.10.0 diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 33b63bc..115747f 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -2061,10 +2061,27 @@ static void bfq_bfqq_save_state(struct bfq_queue *bfqq) bic->saved_IO_bound = bfq_bfqq_IO_bound(bfqq); bic->saved_in_large_burst = bfq_bfqq_in_large_burst(bfqq); bic->was_in_burst_list = !hlist_unhashed(&bfqq->burst_list_node); - bic->saved_wr_coeff = bfqq->wr_coeff; - bic->saved_wr_start_at_switch_to_srt = bfqq->wr_start_at_switch_to_srt; - bic->saved_last_wr_start_finish = bfqq->last_wr_start_finish; - bic->saved_wr_cur_max_time = bfqq->wr_cur_max_time; + if (unlikely(bfq_bfqq_just_created(bfqq) && + !bfq_bfqq_in_large_burst(bfqq))) { + /* + * bfqq being merged right after being created: bfqq + * would have deserved interactive weight raising, but + * did not make it to be set in a weight-raised state, + * because of this early merge. Store directly the + * weight-raising state that would have been assigned + * to bfqq, so that to avoid that bfqq unjustly fails + * to enjoy weight raising if split soon. + */ + bic->saved_wr_coeff = bfqq->bfqd->bfq_wr_coeff; + bic->saved_wr_cur_max_time = bfq_wr_duration(bfqq->bfqd); + bic->saved_last_wr_start_finish = jiffies; + } else { + bic->saved_wr_coeff = bfqq->wr_coeff; + bic->saved_wr_start_at_switch_to_srt = + bfqq->wr_start_at_switch_to_srt; + bic->saved_last_wr_start_finish = bfqq->last_wr_start_finish; + bic->saved_wr_cur_max_time = bfqq->wr_cur_max_time; + } } static void @@ -4150,7 +4167,6 @@ static void __bfq_insert_request(struct bfq_data *bfqd, struct request *rq) new_bfqq->allocated++; bfqq->allocated--; new_bfqq->ref++; - bfq_clear_bfqq_just_created(bfqq); /* * If the bic associated with the process * issuing this request still points to bfqq @@ -4162,6 +4178,8 @@ static void __bfq_insert_request(struct bfq_data *bfqd, struct request *rq) if (bic_to_bfqq(RQ_BIC(rq), 1) == bfqq) bfq_merge_bfqqs(bfqd, RQ_BIC(rq), bfqq, new_bfqq); + + bfq_clear_bfqq_just_created(bfqq); /* * rq is about to be enqueued into new_bfqq, * release rq reference on bfqq