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: 113202 Delivered-To: patch@linaro.org Received: by 10.140.106.117 with SMTP id d108csp1771607qgf; Thu, 21 Sep 2017 02:05:08 -0700 (PDT) X-Received: by 10.84.225.134 with SMTP id u6mr4797185plj.177.1505984708384; Thu, 21 Sep 2017 02:05:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1505984708; cv=none; d=google.com; s=arc-20160816; b=oFUeckaWivIr9apgSWEyVjPAOg6kw1pPQRHcvo/ujiMN0PpbAO1GLBCSlDJu7nDIvD bMDdyEMjsqiLXM/+35davtfVnNmkzp3ze6T1qLnx8/n9g3ABBpfvX7jHRoSbkw7pDdQh SLnw0sw6xyJYZTAsCmY/LGshTlPEW8bfh1p5TGbAglN1z2jcsH5i39OXRtChfwkM4KlK 7MuNzyQntsnmU/GVLKdq55Jf1dadFOMppS8+S6u+bv6lg9UGQlO+6zysT00o5LhvSZeV 7kajV02BnHdESudnqlkr97nYE5qUagpdHOjxz89F6a4i14I4lS7fJ1AgGtMJGhd+m+3/ xXgA== 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=7APZHhwuSzQ/zmaf8APvmTA69ocmpI97R4Mw+O0CVWQ=; b=TyRT5OLlN0+iiTTUXDyE8P7ki8jfhH6j5ngZvkHzU21VNcB9AR5ZLd+cMCFB7k+6O2 MKvAyjia5bEVZ0yH8nUeqEi85QS215kjAtA86W+JGTbb7floyZyi43fSGJGb5iXFFVwb WmwM4NZGThTGQz9mKG71s1hmmzkWQz7vIGdrhiiWCmdwVUhckEjOYDGDKm7QYpk0CsEc V+sWAY861wiHCPoZnhpWZxsBTW5LLZuN1LYDdRR+7p0a3HTdfZ98GBo+hQOYvqqg81W9 1G4TpyDHznWzu8e9VbcqoQ2T5F5hjmgqaM6a6r01KGd+jRzsaVFXpuBIjZkLdS37YPJz YWzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=UbcmyTr2; 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 w5si724870pgt.179.2017.09.21.02.05.07; Thu, 21 Sep 2017 02:05:08 -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=UbcmyTr2; 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 S1752114AbdIUJFF (ORCPT + 26 others); Thu, 21 Sep 2017 05:05:05 -0400 Received: from mail-wr0-f175.google.com ([209.85.128.175]:43320 "EHLO mail-wr0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752054AbdIUJEp (ORCPT ); Thu, 21 Sep 2017 05:04:45 -0400 Received: by mail-wr0-f175.google.com with SMTP id a43so4029572wrc.0 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=p3ZbJjcaR0T3y5m6hFpVWow/S/ZYHcmSscON3+Xo+bgBoPA/fzns1hP6rLw0sEIw00 1mBLRiQeP+1KMj5Bmwqg4gXrMQPpJukGA/pXmOVBdMBUmv5LcqUVWqFQ7gh/fjA7qwQR n7TUjRTXXpvb8eGFa9qLn1icr39KcI5o2yqGTWpXJRwB5sKXosacAUqDHPiOQNJ1xBVT nOkX7Wgd0Mm5eeT9uJjk2R+vW2yeVHcPX5nKA6+mZqMxOmoepRjFSWGNxvgw11RbIy2w vX8kOPIoMUeJ4OArs3M68luEFm7LLJW40A/SfzROX+SWwIVYn04hzDRVJw0EY1xLvgqu 1k6Q== X-Gm-Message-State: AHPjjUirjPkPwmv2Qqi7rbt+dnbEUO+wLqxDk4fKHC2PVZv0GQc2A6yM 1rcdZuE1JFdgiK21rsWrtBA1RA== 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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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(-) -- 2.10.0 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