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: 9963601 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id DE03E600C5 for ; Thu, 21 Sep 2017 09:05:03 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D1A832942F for ; Thu, 21 Sep 2017 09:05:03 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C62EC29433; Thu, 21 Sep 2017 09:05:03 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 63AAB2942F for ; Thu, 21 Sep 2017 09:05:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752056AbdIUJEq (ORCPT ); Thu, 21 Sep 2017 05:04:46 -0400 Received: from mail-wm0-f46.google.com ([74.125.82.46]:48073 "EHLO mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752030AbdIUJEn (ORCPT ); Thu, 21 Sep 2017 05:04:43 -0400 Received: by mail-wm0-f46.google.com with SMTP id 13so13557142wmq.2 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=Sw03ilIkPshJb5cFxTE6hQRHutBAPBns1LT/pgQN3tXUE7pwkle5paTgIOLsHKeI6c zZrNfhjbQ1sM+HX193mCM+/+nGtfbRzZaIrwZYpzpHWwdbQw0IUWC7a812xWFZbWEdoA 0XUJ8w+TvFcafO4HwhcZx1dhJ0V08UzZBWuysJ5p5mJsf59WkNjrUDmk7g6XIBUFeL9/ tdyI9/1GkP3k00mf6KBcqxCG/TpZwPR0p1s9gCaIUTACjvQRDXml6wYrIxWCBquR0jO0 hJ7TUOhKNFGr/Em9EXzwD4eN3iEFmEhGpQjCvTk2531h3Bn3EQzvc0snOqIeJBcya5dy vd9w== X-Gm-Message-State: AHPjjUhzVeh5plIXZz+qgOSJPjed6JMO5gNyiGVzaatZsDu/5ij8HUfQ q2kAtQVAJaE1q+we3YYb9J5m4A== 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-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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(-) 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