From patchwork Thu Sep 21 09:04:03 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 9963605 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 9D99D600C5 for ; Thu, 21 Sep 2017 09:05:19 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 913CE2937B for ; Thu, 21 Sep 2017 09:05:19 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 85E5329430; Thu, 21 Sep 2017 09:05:19 +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=-6.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_HI,RCVD_IN_SORBS_SPAM 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 D29C529425 for ; Thu, 21 Sep 2017 09:05:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752039AbdIUJFE (ORCPT ); Thu, 21 Sep 2017 05:05:04 -0400 Received: from mail-wr0-f174.google.com ([209.85.128.174]:55723 "EHLO mail-wr0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751930AbdIUJEp (ORCPT ); Thu, 21 Sep 2017 05:04:45 -0400 Received: by mail-wr0-f174.google.com with SMTP id l39so4008890wrl.12 for ; Thu, 21 Sep 2017 02:04:45 -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=7APZHhwuSzQ/zmaf8APvmTA69ocmpI97R4Mw+O0CVWQ=; b=UbcmyTr2OWbowdVv8BJyI71Q3qrJyPzvlL7rEfViu5R6Ulz7la3x7XFFZYqZPgqTYY hWC5KMdChbnK10kygJjlSsmVl21PB2bWvErLH0Gp4DJKKrE8+EKz5auPEGKJDsBDawsv ui3S2gRnlrKfmfIR92VPBss3L71qefhmF74GI= 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=7APZHhwuSzQ/zmaf8APvmTA69ocmpI97R4Mw+O0CVWQ=; b=P5SYlXOkrJIXr5lYB6WEvL4E3/yREErOcaQKfwxsGV+7wwHXtzex/eP/VHxebbmjEz cIsQL7ns9ip58VTErhGBcYsQlfwk2HlTjqDsb0h/UZXnUUUZV0Aw/UZZOWXPpmuYl3zT UzC9rBnFjSaXPnYTano43mAWQtt3mIbIC/bfFyTzWonqlWpyZDkM2YUgFresVenzFzpy zA+T6PsSPjsvQRvJ/ruHxl8GCEoPExx3gIP/sAiN7yg6r3o3TtZ2Kxl3p+bxB86qiJGT OCDVpic4yycWkfLtqboxMfRF34uETAEtI7GXX/Q5UpaqIDulahz1EgbXjTIwB15O9HHT JhTQ== X-Gm-Message-State: AHPjjUhOdU7cOYCGKmGwMPsb50Q73+Uo9Vmm7FIGM04ShVTSRL3OhXbQ /T82WZskM73H0gMF2hk2xrKrQw== X-Google-Smtp-Source: AOwi7QCvddwUjTsikpom8/7aVHRWu0KFUWibTv0Ow7bQdXq5nQeNdj0wmbonrzwqI+7GgA18ckGMJw== X-Received: by 10.223.132.225 with SMTP id 88mr1104398wrg.162.1505984684481; Thu, 21 Sep 2017 02:04:44 -0700 (PDT) Received: from localhost.localdomain ([185.14.11.73]) by smtp.gmail.com with ESMTPSA id o59sm804032wrc.45.2017.09.21.02.04.42 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 21 Sep 2017 02:04:43 -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 4/4] block, bfq: decrease burst size when queues in burst exit Date: Thu, 21 Sep 2017 11:04:03 +0200 Message-Id: <20170921090403.3217-5-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 If many queues belonging to the same group happen to be created shortly after each other, then the concurrent processes associated with these queues have typically a common goal, and they get it done as soon as possible if not hampered by device idling. Examples are processes spawned by git grep, or by systemd during boot. As for device idling, this mechanism is currently necessary for weight raising to succeed in its goal: privileging I/O. In view of these facts, BFQ does not provide the above queues with either weight raising or device idling. On the other hand, a burst of queue creations may be caused also by the start-up of a complex application. In this case, these queues need usually to be served one after the other, and as quickly as possible, to maximise responsiveness. Therefore, in this case the best strategy is to weight-raise all the queues created during the burst, i.e., the exact opposite of the strategy for the above case. To distinguish between the two cases, BFQ uses an empirical burst-size threshold, found through extensive tests and monitoring of daily usage. Only large bursts, i.e., burst with a size above this threshold, are considered as generated by a high number of parallel processes. In this respect, upstart-based boot proved to be rather hard to detect as generating a large burst of queue creations, because with upstart most of the queues created in a burst exit *before* the next queues in the same burst are created. To address this issue, I changed the burst-detection mechanism so as to not decrease the size of the current burst even if one of the queues in the burst is eliminated. Unfortunately, this missing decrease causes false positives on very fast systems: on the start-up of a complex application, such as libreoffice writer, so many queues are created, served and exited shortly after each other, that a large burst of queue creations is wrongly detected as occurring. These false positives just disappear if the size of a burst is decreased when one of the queues in the burst exits. This commit restores the missing burst-size decrease, relying of the fact that upstart is apparently unlikely to be used on systems running this and future versions of the kernel. Signed-off-by: Paolo Valente Signed-off-by: Mauro Andreolini Signed-off-by: Angelo Ruocco Tested-by: Mirko Montanari Tested-by: Oleksandr Natalenko --- block/bfq-iosched.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 115747f..70f9177 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -3725,16 +3725,10 @@ void bfq_put_queue(struct bfq_queue *bfqq) if (bfqq->ref) return; - if (bfq_bfqq_sync(bfqq)) - /* - * The fact that this queue is being destroyed does not - * invalidate the fact that this queue may have been - * activated during the current burst. As a consequence, - * although the queue does not exist anymore, and hence - * needs to be removed from the burst list if there, - * the burst size has not to be decremented. - */ + if (bfq_bfqq_sync(bfqq) && !hlist_unhashed(&bfqq->burst_list_node)) { hlist_del_init(&bfqq->burst_list_node); + bfqq->bfqd->burst_size--; + } kmem_cache_free(bfq_pool, bfqq); #ifdef CONFIG_BFQ_GROUP_IOSCHED