From patchwork Thu Sep 21 09:04:00 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 113201 Delivered-To: patch@linaro.org Received: by 10.140.106.117 with SMTP id d108csp1771285qgf; Thu, 21 Sep 2017 02:04:47 -0700 (PDT) X-Received: by 10.98.223.210 with SMTP id d79mr4907692pfl.67.1505984687130; Thu, 21 Sep 2017 02:04:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1505984687; cv=none; d=google.com; s=arc-20160816; b=OC1XzByjy08ZVCRH1I4hXbaCi7BWF92anb8Oou9RJuNqLwES++LPk4MyOw44acKI4j iDZWdP6FCRkAtA4boTxeo+9ZheByQAZj52gLcsywuL5kFtFp3U7FUMZWADIKIqt5nAvt y7H6abS6BRwX/THVmqEzBM7l2/kNeE1vPN0Rw4MBlSsAlp0s/vo3qHU7WKYuqjiIlh2G 2qOX2cjaD7OC466fAiunL/5AXBvK7tTFuVSPtZ5DMoxrjGO3oEl2qaMblR7T2TkhqG/l dYbFnUSAFi/CiZA1ZMm5vxUTVcwLLna/dLbZ3M+RUu6NdzvDWuzMkiVBXtSkbOPjMa6p aKBg== 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=uNlQFKFV+Wjj6fYjhJGqhZUyrQ/O6Mb11TIDJfMIsUY=; b=ymojvtOmEsEdZdWxVJkBIEZwzlqqbfdMbMuw7MVEitda54wz/NTWFfx2Dbo0fzd3pi FDpF/C/DztZ7iocvRx+vKITav9rbCNcXNimQAO7wfbsVGzjVNE67oLWAGhRFZ1W8dvr2 nOSX7e+YAhKBoD3sCTqFn20v4U2leIJEVaIN9Dmbeff9XIwbfofSsCWhB+kAiFc9T7oX 7KCN9wE36183+R2ZvNJp7ya1pb/Pcj8ONnNxGoG1ljeau02O2canBFbbCFFnr0hwzLJh yog9civfxT2Pcsi+o4PY9IpzDMDjcgzz+UW9FcIDcaILood2Zz47KQXAJ9TBzwzBzV5Y 7g3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=BNh5Ll53; 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 a6si717279pll.406.2017.09.21.02.04.46; Thu, 21 Sep 2017 02:04:47 -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=BNh5Ll53; 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 S1752053AbdIUJEn (ORCPT + 26 others); Thu, 21 Sep 2017 05:04:43 -0400 Received: from mail-wr0-f179.google.com ([209.85.128.179]:50441 "EHLO mail-wr0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751930AbdIUJEj (ORCPT ); Thu, 21 Sep 2017 05:04:39 -0400 Received: by mail-wr0-f179.google.com with SMTP id w12so4009053wrc.7 for ; Thu, 21 Sep 2017 02:04:38 -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=uNlQFKFV+Wjj6fYjhJGqhZUyrQ/O6Mb11TIDJfMIsUY=; b=BNh5Ll53WgOWL3yr3be09uPAffWbTCRztp+QqdaAfZidzP20mnKO8b2NP0sr1ePNAN at4/X2vpEPBT5WXao3ofQw0ai6DJpElyM9/ecZYOsqDqcPljOo/qb4zczQ9/4OFom1UG A3Viep4LKvWoICFWF6X9O8aPBV5t69dyl8ZyI= 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=uNlQFKFV+Wjj6fYjhJGqhZUyrQ/O6Mb11TIDJfMIsUY=; b=t+wn1gLtcxlDQ33H9LavyiNGhJP8NX19X5HHYKdWe77SnR2GCMxdQy3w7sWNANj79k OtKG5S7Z4gHSO4vhPPFCkXZ4GXMEvxXPvs9bZ/vt775cgZeahjcZOnMvkqtHW0gmxH8J iObnFGWgE+5i9stp07lcDvz/wrBq7d3tYExIj7qmyGQ0j96DUEvRd3upjWeQlbftAxla 6XZOq+tpQxOGNJ3eCOnC8OV5WGgXEGws++R0re2Wq4HXtiafGwViRXRi3L/3PMREKxsH 5WP2io1J1lDbbYwT7t51qUOU8OjOHzGFG3yDRcl/iWH8Z4SJBS2aYJSdPvElXbKdAmPG 0Dvg== X-Gm-Message-State: AHPjjUg0TSZEe9V5dKW1zV41b5KenmLAcocqBR6cLrgN/b9QpIBka9+6 o1Aih7Y0uPqaQ9GAOA0ni+1J3ptmGeQ= X-Google-Smtp-Source: AOwi7QCFmD1Tj+iNnizs7nKivETWMNJeIAtHb6X6DVHKLp5FXWl5eIMuwzunzApAM8qntczUbyWwxg== X-Received: by 10.223.182.71 with SMTP id i7mr1170202wre.43.1505984678128; Thu, 21 Sep 2017 02:04:38 -0700 (PDT) Received: from localhost.localdomain ([185.14.11.73]) by smtp.gmail.com with ESMTPSA id o59sm804032wrc.45.2017.09.21.02.04.36 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 21 Sep 2017 02:04:37 -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 1/4] block, bfq: fix wrong init of saved start time for weight raising Date: Thu, 21 Sep 2017 11:04:00 +0200 Message-Id: <20170921090403.3217-2-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 This commit fixes a bug that causes bfq to fail to guarantee a high responsiveness on some drives, if there is heavy random read+write I/O in the background. More precisely, such a failure allowed this bug to be found [1], but the bug may well cause other yet unreported anomalies. BFQ raises the weight of the bfq_queues associated with soft real-time applications, to privilege the I/O, and thus reduce latency, for these applications. This mechanism is named soft-real-time weight raising in BFQ. A soft real-time period may happen to be nested into an interactive weight raising period, i.e., it may happen that, when a bfq_queue switches to a soft real-time weight-raised state, the bfq_queue is already being weight-raised because deemed interactive too. In this case, BFQ saves in a special variable wr_start_at_switch_to_srt, the time instant when the interactive weight-raising period started for the bfq_queue, i.e., the time instant when BFQ started to deem the bfq_queue interactive. This value is then used to check whether the interactive weight-raising period would still be in progress when the soft real-time weight-raising period ends. If so, interactive weight raising is restored for the bfq_queue. This restore is useful, in particular, because it prevents bfq_queues from losing their interactive weight raising prematurely, as a consequence of spurious, short-lived soft real-time weight-raising periods caused by wrong detections as soft real-time. If, instead, a bfq_queue switches to soft-real-time weight raising while it *is not* already in an interactive weight-raising period, then the variable wr_start_at_switch_to_srt has no meaning during the following soft real-time weight-raising period. Unfortunately the handling of this case is wrong in BFQ: not only the variable is not flagged somehow as meaningless, but it is also set to the time when the switch to soft real-time weight-raising occurs. This may cause an interactive weight-raising period to be considered mistakenly as still in progress, and thus a spurious interactive weight-raising period to start for the bfq_queue, at the end of the soft-real-time weight-raising period. In particular the spurious interactive weight-raising period will be considered as still in progress, if the soft-real-time weight-raising period does not last very long. The bfq_queue will then be wrongly privileged and, if I/O bound, will unjustly steal bandwidth to truly interactive or soft real-time bfq_queues, harming responsiveness and low latency. This commit fixes this issue by just setting wr_start_at_switch_to_srt to minus infinity (farthest past time instant according to jiffies macros): when the soft-real-time weight-raising period ends, certainly no interactive weight-raising period will be considered as still in progress. [1] Background I/O Type: Random - Background I/O mix: Reads and writes - Application to start: LibreOffice Writer in http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.13-IO-Laptop Signed-off-by: Paolo Valente Signed-off-by: Angelo Ruocco Tested-by: Oleksandr Natalenko Tested-by: Lee Tibbert Tested-by: Mirko Montanari --- block/bfq-iosched.c | 50 +++++++++++++++++++++++++++++++------------------- 1 file changed, 31 insertions(+), 19 deletions(-) -- 2.10.0 diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index a4783da..c25955c 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -1202,6 +1202,24 @@ static unsigned int bfq_wr_duration(struct bfq_data *bfqd) return dur; } +/* + * Return the farthest future time instant according to jiffies + * macros. + */ +static unsigned long bfq_greatest_from_now(void) +{ + return jiffies + MAX_JIFFY_OFFSET; +} + +/* + * Return the farthest past time instant according to jiffies + * macros. + */ +static unsigned long bfq_smallest_from_now(void) +{ + return jiffies - MAX_JIFFY_OFFSET; +} + static void bfq_update_bfqq_wr_on_rq_arrival(struct bfq_data *bfqd, struct bfq_queue *bfqq, unsigned int old_wr_coeff, @@ -1216,7 +1234,19 @@ static void bfq_update_bfqq_wr_on_rq_arrival(struct bfq_data *bfqd, bfqq->wr_coeff = bfqd->bfq_wr_coeff; bfqq->wr_cur_max_time = bfq_wr_duration(bfqd); } else { - bfqq->wr_start_at_switch_to_srt = jiffies; + /* + * No interactive weight raising in progress + * here: assign minus infinity to + * wr_start_at_switch_to_srt, to make sure + * that, at the end of the soft-real-time + * weight raising periods that is starting + * now, no interactive weight-raising period + * may be wrongly considered as still in + * progress (and thus actually started by + * mistake). + */ + bfqq->wr_start_at_switch_to_srt = + bfq_smallest_from_now(); bfqq->wr_coeff = bfqd->bfq_wr_coeff * BFQ_SOFTRT_WEIGHT_FACTOR; bfqq->wr_cur_max_time = @@ -2897,24 +2927,6 @@ static unsigned long bfq_bfqq_softrt_next_start(struct bfq_data *bfqd, jiffies + nsecs_to_jiffies(bfqq->bfqd->bfq_slice_idle) + 4); } -/* - * Return the farthest future time instant according to jiffies - * macros. - */ -static unsigned long bfq_greatest_from_now(void) -{ - return jiffies + MAX_JIFFY_OFFSET; -} - -/* - * Return the farthest past time instant according to jiffies - * macros. - */ -static unsigned long bfq_smallest_from_now(void) -{ - return jiffies - MAX_JIFFY_OFFSET; -} - /** * bfq_bfqq_expire - expire a queue. * @bfqd: device owning the queue. 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; } } 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 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