From patchwork Fri Jun 5 14:16:16 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Kara X-Patchwork-Id: 11589781 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 315A5912 for ; Fri, 5 Jun 2020 14:16:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2045D20835 for ; Fri, 5 Jun 2020 14:16:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728253AbgFEOQc (ORCPT ); Fri, 5 Jun 2020 10:16:32 -0400 Received: from mx2.suse.de ([195.135.220.15]:42444 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728241AbgFEOQb (ORCPT ); Fri, 5 Jun 2020 10:16:31 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 13E65AAD0; Fri, 5 Jun 2020 14:16:33 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 4D67A1E0267; Fri, 5 Jun 2020 16:16:29 +0200 (CEST) From: Jan Kara To: Cc: Paolo Valente , Jan Kara , stable@vger.kernel.org Subject: [PATCH 1/3] bfq: Avoid false bfq queue merging Date: Fri, 5 Jun 2020 16:16:16 +0200 Message-Id: <20200605141629.15347-1-jack@suse.cz> X-Mailer: git-send-email 2.16.4 In-Reply-To: <20200605140837.5394-1-jack@suse.cz> References: <20200605140837.5394-1-jack@suse.cz> Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org bfq_setup_cooperator() uses bfqd->in_serv_last_pos so detect whether it makes sense to merge current bfq queue with the in-service queue. However if the in-service queue is freshly scheduled and didn't dispatch any requests yet, bfqd->in_serv_last_pos is stale and contains value from the previously scheduled bfq queue which can thus result in a bogus decision that the two queues should be merged. This bug can be observed for example with the following fio jobfile: [global] direct=0 ioengine=sync invalidate=1 size=1g rw=read [reader] numjobs=4 directory=/mnt where the 4 processes will end up in the one shared bfq queue although they do IO to physically very distant files (for some reason I was able to observe this only with slice_idle=1ms setting). Fix the problem by invalidating bfqd->in_serv_last_pos when switching in-service queue. Fixes: 058fdecc6de7 ("block, bfq: fix in-service-queue check for queue merging") CC: stable@vger.kernel.org Signed-off-by: Jan Kara Acked-by: Paolo Valente Acked-by: Paolo Valente --- block/bfq-iosched.c | 1 + 1 file changed, 1 insertion(+) diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 3d411716d7ee..50017275915f 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -2937,6 +2937,7 @@ static void __bfq_set_in_service_queue(struct bfq_data *bfqd, } bfqd->in_service_queue = bfqq; + bfqd->in_serv_last_pos = 0; } /* From patchwork Wed Jan 13 10:09:26 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Kara X-Patchwork-Id: 12016373 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8C698C43381 for ; Wed, 13 Jan 2021 10:10:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 44ECB233A2 for ; Wed, 13 Jan 2021 10:10:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727233AbhAMKKU (ORCPT ); Wed, 13 Jan 2021 05:10:20 -0500 Received: from mx2.suse.de ([195.135.220.15]:44666 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727206AbhAMKKT (ORCPT ); Wed, 13 Jan 2021 05:10:19 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 00D71B773; Wed, 13 Jan 2021 10:09:38 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id B76EA1E086D; Wed, 13 Jan 2021 11:09:37 +0100 (CET) From: Jan Kara To: Jens Axboe Cc: , Paolo Valente , Jan Kara Subject: [PATCH 2/3] bfq: Use 'ttime' local variable Date: Wed, 13 Jan 2021 11:09:26 +0100 Message-Id: <20210113100937.8278-2-jack@suse.cz> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200605140837.5394-1-jack@suse.cz> References: <20200605140837.5394-1-jack@suse.cz> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org Use local variable 'ttime' instead of dereferencing bfqq. Acked-by: Paolo Valente Signed-off-by: Jan Kara --- block/bfq-iosched.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index dc5f12d0d482..d0b744eae1a3 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -5199,7 +5199,7 @@ static void bfq_update_io_thinktime(struct bfq_data *bfqd, elapsed = min_t(u64, elapsed, 2ULL * bfqd->bfq_slice_idle); - ttime->ttime_samples = (7*bfqq->ttime.ttime_samples + 256) / 8; + ttime->ttime_samples = (7*ttime->ttime_samples + 256) / 8; ttime->ttime_total = div_u64(7*ttime->ttime_total + 256*elapsed, 8); ttime->ttime_mean = div64_ul(ttime->ttime_total + 128, ttime->ttime_samples); From patchwork Wed Jan 13 10:09:27 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Kara X-Patchwork-Id: 12016371 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E9B36C433E0 for ; Wed, 13 Jan 2021 10:10:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9157B23370 for ; Wed, 13 Jan 2021 10:10:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727222AbhAMKKT (ORCPT ); Wed, 13 Jan 2021 05:10:19 -0500 Received: from mx2.suse.de ([195.135.220.15]:44670 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727003AbhAMKKT (ORCPT ); Wed, 13 Jan 2021 05:10:19 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id ED73FAC5B; Wed, 13 Jan 2021 10:09:37 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id BC3F81E0871; Wed, 13 Jan 2021 11:09:37 +0100 (CET) From: Jan Kara To: Jens Axboe Cc: , Paolo Valente , Jan Kara Subject: [PATCH 3/3] bfq: Use only idle IO periods for think time calculations Date: Wed, 13 Jan 2021 11:09:27 +0100 Message-Id: <20210113100937.8278-3-jack@suse.cz> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200605140837.5394-1-jack@suse.cz> References: <20200605140837.5394-1-jack@suse.cz> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org Currently whenever bfq queue has a request queued we add now - last_completion_time to the think time statistics. This is however misleading in case the process is able to submit several requests in parallel because e.g. if the queue has request completed at time T0 and then queues new requests at times T1, T2, then we will add T1-T0 and T2-T0 to think time statistics which just doesn't make any sence (the queue's think time is penalized by the queue being able to submit more IO). So add to think time statistics only time intervals when the queue had no IO pending. Acked-by: Paolo Valente Signed-off-by: Jan Kara --- block/bfq-iosched.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index d0b744eae1a3..53e6e76b98af 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -5195,8 +5195,16 @@ static void bfq_update_io_thinktime(struct bfq_data *bfqd, struct bfq_queue *bfqq) { struct bfq_ttime *ttime = &bfqq->ttime; - u64 elapsed = ktime_get_ns() - bfqq->ttime.last_end_request; + u64 elapsed; + /* + * We are really interested in how long it takes for the queue to + * become busy when there is no outstanding IO for this queue. So + * ignore cases when the bfq queue has already IO queued. + */ + if (bfqq->dispatched || bfq_bfqq_busy(bfqq)) + return; + elapsed = ktime_get_ns() - bfqq->ttime.last_end_request; elapsed = min_t(u64, elapsed, 2ULL * bfqd->bfq_slice_idle); ttime->ttime_samples = (7*ttime->ttime_samples + 256) / 8;