From patchwork Wed Dec 20 11:38:34 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 122463 Delivered-To: patch@linaro.org Received: by 10.140.22.227 with SMTP id 90csp5452761qgn; Wed, 20 Dec 2017 03:40:13 -0800 (PST) X-Google-Smtp-Source: ACJfBotq6KYtivqxj+lGrBmTAZwRiUctPSA5gm6zUM4hvyJyifD17sE4UXnqhxD+1ujMoSnkUOqK X-Received: by 10.124.22.132 with SMTP id v4mr6647175ply.158.1513770013648; Wed, 20 Dec 2017 03:40:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1513770013; cv=none; d=google.com; s=arc-20160816; b=wOxJuucfPj/FEBWvJ+g4mxnyKo2QWAO7SwvA+Hj911Ss5uaQiazyfTGt+Nst7bmPZG Bhi7/C5DLfIanhE+t1WQYHYUIgCcl0X1t0ObIabGG2HCNS4iqvMoO2XYsGQitnX6YGka pXtwT1wzgOEck9ewUbpcUEtJmBpffxmsdpSenliFGcsVieAD4huYN69k98kyOHNJwcZJ Xk5mxGZqflsiCCvLZRKx4oHvvtbnyWgKJtQ+6Na0omEPT84eX9zkcWXZxglerf7CtXfu dSHx9xBshZz4BgGq38U/e3PCdOL8rKXD+UxsS6bLQNk/evmHh3Vai1AA8vorhXY64CGh BUFw== 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=73hnCDqCmB0yErZn73n7WIhPPJ+L4UI2WUpvPNLSBng=; b=i4yKbanNH3c/VqYh/Mkmh+/pq5GPJsJ+9KdOio4oukRTPJnVHt5jjvk7GaU1PqlSjX fQBcSWOtiZ34J/HEzo2vBsqfSkyC8bjLNelduspcU2EAi1cLyaXyhlb/dW+Yr4xYU3yN imKjqBrcpI9y659pyEnTaFmd/EcWQO9lG5KKds3WE/RRvSUcUuZW5GpnrK9H0WTODP06 Rx/j64GVa90KL7wUdUXPTWdHWON6tq4VnvH9KLbifiANKe1u1Ugy0U9ugw7whGc/YxY3 aVOFw45Dypf/pE/Oa9Q+4m3owiCFzZ/QkX4BvvWRsDaOSKisQO03ymVCBo2pOmihU/5P l5kg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=NzxWsIG8; 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 o1si743175pgp.166.2017.12.20.03.40.13; Wed, 20 Dec 2017 03:40:13 -0800 (PST) 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=NzxWsIG8; 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 S1755187AbdLTLkJ (ORCPT + 28 others); Wed, 20 Dec 2017 06:40:09 -0500 Received: from mail-wm0-f66.google.com ([74.125.82.66]:44128 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754985AbdLTLj0 (ORCPT ); Wed, 20 Dec 2017 06:39:26 -0500 Received: by mail-wm0-f66.google.com with SMTP id t8so9229035wmc.3 for ; Wed, 20 Dec 2017 03:39:26 -0800 (PST) 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=73hnCDqCmB0yErZn73n7WIhPPJ+L4UI2WUpvPNLSBng=; b=NzxWsIG8CxjlsK54zzooTn+pUaJ4rBiOr9trjOLKx8WWEvPsQnlGWbTm4iLMWyR+cy +hN408BaqR7nmt1Ilk30GcsrvHrSY38ERNq4HYx3m+TkW8cbE50MQoS4hxoYoxORHR8p VO3bSMpPdl6uqotk2BI1H9K1/ScnLHibIv7Fs= 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=73hnCDqCmB0yErZn73n7WIhPPJ+L4UI2WUpvPNLSBng=; b=XHcGLypk8sq0bkp8eeNGRAzDa9Mo38damhgbXlX56rZHMulBwEWbGzYMmCHY6ppapu cW648QbXgaXDcUMb//ir6vTdMoOy+FOrJp7WzI1OuJICHuEXfHBA9s/AyETdH00u4ln7 3qlD3uIUdEIDIlV8MtXadC5aOabyXlMLwhK6wJTtTQUIX/V2N3CBnWvJLmf9rCTxDSLG 6EJRTPaq+cTfxNheLEC88+REuYchO4NkKRK/yg2WtindajM7+m8kTIPlaOcT04R9B6Me PI1eBmiH9fb3oT0GD6xLfpMHf2NL2bzUsoxGdTX7MQ7ib7p8zqbzMmK1Cg400flz2kWu rowg== X-Gm-Message-State: AKGB3mLeBDLXMyn3Juy9PHRAr2Wv9agzO45CNSAUMpvP3pKrSTK1Cl47 x07ZOSx9h7eDxP+ZRBYSVtVmdQ== X-Received: by 10.28.222.132 with SMTP id v126mr6196602wmg.127.1513769965375; Wed, 20 Dec 2017 03:39:25 -0800 (PST) Received: from wifi-122_dhcprange-89.wifi.unimo.it (wifi-122_dhcprange-89.wifi.unimo.it. [155.185.122.89]) by smtp.gmail.com with ESMTPSA id o27sm9704436wro.9.2017.12.20.03.39.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Dec 2017 03:39:24 -0800 (PST) From: Paolo Valente To: Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, ulf.hansson@linaro.org, broonie@kernel.org, linus.walleij@linaro.org, angeloruocco90@gmail.com, bfq-iosched@googlegroups.com, Paolo Valente Subject: [PATCH IMPROVEMENT/BUGFIX 4/4] block, bfq: remove superfluous check in queue-merging setup Date: Wed, 20 Dec 2017 12:38:34 +0100 Message-Id: <20171220113834.2578-5-paolo.valente@linaro.org> X-Mailer: git-send-email 2.15.1 In-Reply-To: <20171220113834.2578-1-paolo.valente@linaro.org> References: <20171220113834.2578-1-paolo.valente@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Angelo Ruocco When two or more processes do I/O in a way that the their requests are sequential in respect to one another, BFQ merges the bfq_queues associated with the processes. This way the overall I/O pattern becomes sequential, and thus there is a boost in througput. These cooperating processes usually start or restart to do I/O shortly after each other. So, in order to avoid merging non-cooperating processes, BFQ ensures that none of these queues has been in weight raising for too long. In this respect, from commit "block, bfq-sq, bfq-mq: let a queue be merged only shortly after being created", BFQ checks whether any queue (and not only weight-raised ones) is doing I/O continuously from too long to be merged. This new additional check makes the first one useless: a queue doing I/O from long enough, if being weight-raised, is also a queue in weight raising for too long to be merged. Accordingly, this commit removes the first check. Signed-off-by: Angelo Ruocco Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 36 +++++------------------------------- 1 file changed, 5 insertions(+), 31 deletions(-) -- 2.15.1 diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 320022135dc8..c66578592c9e 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -1990,20 +1990,6 @@ static bool bfq_may_be_close_cooperator(struct bfq_queue *bfqq, return true; } -/* - * If this function returns true, then bfqq cannot be merged. The idea - * is that true cooperation happens very early after processes start - * to do I/O. Usually, late cooperations are just accidental false - * positives. In case bfqq is weight-raised, such false positives - * would evidently degrade latency guarantees for bfqq. - */ -static bool wr_from_too_long(struct bfq_queue *bfqq) -{ - return bfqq->wr_coeff > 1 && - time_is_before_jiffies(bfqq->last_wr_start_finish + - msecs_to_jiffies(100)); -} - /* * Attempt to schedule a merge of bfqq with the currently in-service * queue or with a close queue among the scheduled queues. Return @@ -2017,11 +2003,6 @@ static bool wr_from_too_long(struct bfq_queue *bfqq) * to maintain. Besides, in such a critical condition as an out of memory, * the benefits of queue merging may be little relevant, or even negligible. * - * Weight-raised queues can be merged only if their weight-raising - * period has just started. In fact cooperating processes are usually - * started together. Thus, with this filter we avoid false positives - * that would jeopardize low-latency guarantees. - * * WARNING: queue merging may impair fairness among non-weight raised * queues, for at least two reasons: 1) the original weight of a * merged queue may change during the merged state, 2) even being the @@ -2052,9 +2033,7 @@ bfq_setup_cooperator(struct bfq_data *bfqd, struct bfq_queue *bfqq, if (bfqq->new_bfqq) return bfqq->new_bfqq; - if (!io_struct || - wr_from_too_long(bfqq) || - unlikely(bfqq == &bfqd->oom_bfqq)) + if (!io_struct || unlikely(bfqq == &bfqd->oom_bfqq)) return NULL; /* If there is only one backlogged queue, don't search. */ @@ -2063,12 +2042,9 @@ bfq_setup_cooperator(struct bfq_data *bfqd, struct bfq_queue *bfqq, in_service_bfqq = bfqd->in_service_queue; - if (!in_service_bfqq || in_service_bfqq == bfqq - || wr_from_too_long(in_service_bfqq) || - unlikely(in_service_bfqq == &bfqd->oom_bfqq)) - goto check_scheduled; - - if (bfq_rq_close_to_sector(io_struct, request, bfqd->last_position) && + if (in_service_bfqq && in_service_bfqq != bfqq && + likely(in_service_bfqq != &bfqd->oom_bfqq) && + bfq_rq_close_to_sector(io_struct, request, bfqd->last_position) && bfqq->entity.parent == in_service_bfqq->entity.parent && bfq_may_be_close_cooperator(bfqq, in_service_bfqq)) { new_bfqq = bfq_setup_merge(bfqq, in_service_bfqq); @@ -2080,12 +2056,10 @@ bfq_setup_cooperator(struct bfq_data *bfqd, struct bfq_queue *bfqq, * queues. The only thing we need is that the bio/request is not * NULL, as we need it to establish whether a cooperator exists. */ -check_scheduled: new_bfqq = bfq_find_close_cooperator(bfqd, bfqq, bfq_io_struct_pos(io_struct, request)); - if (new_bfqq && !wr_from_too_long(new_bfqq) && - likely(new_bfqq != &bfqd->oom_bfqq) && + if (new_bfqq && likely(new_bfqq != &bfqd->oom_bfqq) && bfq_may_be_close_cooperator(bfqq, new_bfqq)) return bfq_setup_merge(bfqq, new_bfqq);