Message ID | 20221013135321.174-1-Yuwei.Guan@zeekrlife.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp297684wrs; Thu, 13 Oct 2022 07:06:26 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5m5riQ41gJVsoKitcrmA0rK+Lj7EaMPDYKF3kS0YhsBH2weyUOXbvjgG8qJZ2k317L92Ku X-Received: by 2002:a05:6402:847:b0:45c:c716:4b76 with SMTP id b7-20020a056402084700b0045cc7164b76mr5835512edz.113.1665669986349; Thu, 13 Oct 2022 07:06:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665669986; cv=none; d=google.com; s=arc-20160816; b=NMwVCiSqb+YIgLeXCvmwFcXJDtwKY08hp55TzmMtGAx5f9Mb4yyokOslgn0tie7jfk ntinXEe5ni8cwB/04qLf7xvlqbp+eIgvMSvJwEsH2g182i+CooLoY1aLwJzsN/p/2dqj 56lkMijprd42nqqvrHVwHqR4cHSEhzwJSfMQMEBAPpKVIy1dck0ZxyEBG1jqFIlHy8qT 1LxJLis2bG/dM8aIxxPrCriobkTuvdesDGH/5BCaq9QflyzIN5g2yfUqtOo41AB8gxER E6RVWWVun7IixJpZ1LAOX+E/XhYNi9dnGduLZIC71of1FuU+1TMrHAhX9YvH3FXtFMYt q3Ow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=P3lzffeHmbexWVtKhrHG9c286PrH8ea4fn4/VFTKtUI=; b=kGVtYCZBhvhb9+OWyYMBY2SEyz8cEg8y8Twt6SQP3X174+DuUmXZFIHObZyy8sgcag j2pRKb8mZRypib8D773a+c8OnF7daechWR/0PcU7lHle16YVxF7ZlssyNSZukIdcDmEk uG1ayT92H4C9cpkq/OWR+U6ORemuoHEV5bLF6TTJAppGTkymk8ZE5BLfmNMaKyxu5lA+ 2fdwDhE7edO5klrjoj/Q+8WE+KvRIKknUiMPE2+dBcsD1o2F13QBfLhCkkzlPjpBoivR 1t4kND/rmGEljPmtnXcOlCYOX5W4nCUCCh7h9aoTtUCAReJa1DLl1E4Jjcx/XSsJCtZQ 5S+g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=pyTFtbpq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qa15-20020a170907868f00b00779f8e7ec5bsi17505597ejc.42.2022.10.13.07.05.58; Thu, 13 Oct 2022 07:06:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=pyTFtbpq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229954AbiJMOEe (ORCPT <rfc822;ouuuleilei@gmail.com> + 99 others); Thu, 13 Oct 2022 10:04:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59968 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229920AbiJMOE3 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 13 Oct 2022 10:04:29 -0400 Received: from mail-oa1-x2b.google.com (mail-oa1-x2b.google.com [IPv6:2001:4860:4864:20::2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 204D64C032; Thu, 13 Oct 2022 07:04:14 -0700 (PDT) Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-1364357a691so2383861fac.7; Thu, 13 Oct 2022 07:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=P3lzffeHmbexWVtKhrHG9c286PrH8ea4fn4/VFTKtUI=; b=pyTFtbpqkize8kW1Owf9hUAM5zNNJzYmp5MHcfKlmD519xwRmXSE4n8iqx4pQ9Th+f EcsrFVvUa4cZWU89Ca8lSQHMhQ7o+HX8RwhyKWpeyint//6sEXm3SUKO/6Hdp2VanFsd jTkd+EdzA02ULjiIdWxm/w/VfU8FsvHQ/LrjEXJJGHBAURWxBKE4brKJrqOAu6fAcO0a 77THxw6s65Vxah9u6PS2SSm/RhAQMG+tUw+QrerMVy9linXduPhEqu4Mig147SMxMIy8 Q6RrjJN7+bkstFgaRmV1oCSfE4ws23vpFUikNLbok6MHVe4PpKHEGzwWlZgFJeIIgHMi VcZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=P3lzffeHmbexWVtKhrHG9c286PrH8ea4fn4/VFTKtUI=; b=Ekft9pK3bnXqNEG1l7o07LCkv+tjyTs8zu5olIGSDrhp6cNOwl3BwJMMPUgeGRV3gJ LLj6aaJ4JxNI+9FTS7u5KNz++yFPhSt1Zk1wSrWUf+g0zfbki/3/vN4nkWgAypdHKpVF EdopC0VcedtGyce8Hrsu6wjwoe7CLdxrNAV81xCFEP8cBic7AM+wqNwBgS46pn05RXu8 Puam2ZjGVD1MBPqx/RdtZcvS+mRqh0sxkiYHz4kfLFhoXrniCz9eJSCvF7dG/Flldtye uCcBvufrnr/L6eYW3mptJzZqPYd/ZC1sdz0kpgpqr0KzgA2WzYgRMrbmRcTKfYrEateP Ssvw== X-Gm-Message-State: ACrzQf1f94kjgAboXzT37PBKkb3ZymxNRs2alhVGA0jh6TpfbhQpmFUD ch3CYUV5Y0bzeDhNlY5zb2kxThpKaTSSKVzMlaM= X-Received: by 2002:a17:90b:1c0e:b0:20d:8cc5:23e5 with SMTP id oc14-20020a17090b1c0e00b0020d8cc523e5mr9849752pjb.111.1665669252648; Thu, 13 Oct 2022 06:54:12 -0700 (PDT) Received: from Zbook.localdomain ([129.227.152.6]) by smtp.gmail.com with ESMTPSA id s15-20020a170902ea0f00b0016d72804664sm12650457plg.205.2022.10.13.06.54.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Oct 2022 06:54:12 -0700 (PDT) From: Yuwei Guan <ssawgyw@gmail.com> X-Google-Original-From: Yuwei Guan <Yuwei.Guan@zeekrlife.com> To: paolo.valente@linaro.org, axboe@kernel.dk, jack@suse.cz Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Yuwei.Guan@zeekrlife.com Subject: [PATCH] bfq: do try insert merge before bfq_init_rq() call Date: Thu, 13 Oct 2022 21:53:21 +0800 Message-Id: <20221013135321.174-1-Yuwei.Guan@zeekrlife.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1746581571851531618?= X-GMAIL-MSGID: =?utf-8?q?1746581571851531618?= |
Series |
bfq: do try insert merge before bfq_init_rq() call
|
|
Commit Message
Yuwei Guan
Oct. 13, 2022, 1:53 p.m. UTC
It's useless to do bfq_init_rq(rq), if the rq can do merge first.
In the patch 5f550ede5edf8, it moved to bfq_init_rq() before
blk_mq_sched_try_insert_merge(), but it's pointless,
as the fifo_time of next is not set yet,
and !list_empty(&next->queuelist) is 0, so it does not
need to reposition rq's fifo_time.
And for the "hash lookup, try again" situation, as follow,
bfq_requests_merged() call can work normally.
blk_mq_sched_try_insert_merge
elv_attempt_insert_merge
elv_rqhash_find
Signed-off-by: Yuwei Guan <Yuwei.Guan@zeekrlife.com>
---
block/bfq-iosched.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Comments
On Thu 13-10-22 21:53:21, Yuwei Guan wrote: > It's useless to do bfq_init_rq(rq), if the rq can do merge first. > > In the patch 5f550ede5edf8, it moved to bfq_init_rq() before > blk_mq_sched_try_insert_merge(), but it's pointless, > as the fifo_time of next is not set yet, > and !list_empty(&next->queuelist) is 0, so it does not > need to reposition rq's fifo_time. > > And for the "hash lookup, try again" situation, as follow, > bfq_requests_merged() call can work normally. > > blk_mq_sched_try_insert_merge > elv_attempt_insert_merge > elv_rqhash_find > > Signed-off-by: Yuwei Guan <Yuwei.Guan@zeekrlife.com> OK, after some thinking I agree. How much testing has this patch got? Because I'd like to verify we didn't overlook something. Honza > --- > block/bfq-iosched.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c > index 7ea427817f7f..9845370a701c 100644 > --- a/block/bfq-iosched.c > +++ b/block/bfq-iosched.c > @@ -6147,7 +6147,7 @@ static void bfq_insert_request(struct blk_mq_hw_ctx *hctx, struct request *rq, > bfqg_stats_update_legacy_io(q, rq); > #endif > spin_lock_irq(&bfqd->lock); > - bfqq = bfq_init_rq(rq); > + > if (blk_mq_sched_try_insert_merge(q, rq, &free)) { > spin_unlock_irq(&bfqd->lock); > blk_mq_free_requests(&free); > @@ -6156,6 +6156,7 @@ static void bfq_insert_request(struct blk_mq_hw_ctx *hctx, struct request *rq, > > trace_block_rq_insert(rq); > > + bfqq = bfq_init_rq(rq); > if (!bfqq || at_head) { > if (at_head) > list_add(&rq->queuelist, &bfqd->dispatch); > -- > 2.34.1 >
On 2022/10/14 22:50, Jan Kara wrote: > On Thu 13-10-22 21:53:21, Yuwei Guan wrote: >> It's useless to do bfq_init_rq(rq), if the rq can do merge first. >> >> In the patch 5f550ede5edf8, it moved to bfq_init_rq() before >> blk_mq_sched_try_insert_merge(), but it's pointless, >> as the fifo_time of next is not set yet, >> and !list_empty(&next->queuelist) is 0, so it does not >> need to reposition rq's fifo_time. >> >> And for the "hash lookup, try again" situation, as follow, >> bfq_requests_merged() call can work normally. >> >> blk_mq_sched_try_insert_merge >> elv_attempt_insert_merge >> elv_rqhash_find >> >> Signed-off-by: Yuwei Guan <Yuwei.Guan@zeekrlife.com> > OK, after some thinking I agree. How much testing has this patch got? > Because I'd like to verify we didn't overlook something. > > Honza Thanks for reviewing. I tested it with fio seq read case like bellow, then check blk trace and bfq log. [global] name=fio-seq-reads filename=fio-seq-reads rw=read bs=16K direct=1 numjobs=4 [file1] size=32m ioengine=psync What kinds of test cases you perfer to do, I will deal with them, or we verify this patch together, if you have free time. :) >> --- >> block/bfq-iosched.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c >> index 7ea427817f7f..9845370a701c 100644 >> --- a/block/bfq-iosched.c >> +++ b/block/bfq-iosched.c >> @@ -6147,7 +6147,7 @@ static void bfq_insert_request(struct blk_mq_hw_ctx *hctx, struct request *rq, >> bfqg_stats_update_legacy_io(q, rq); >> #endif >> spin_lock_irq(&bfqd->lock); >> - bfqq = bfq_init_rq(rq); >> + >> if (blk_mq_sched_try_insert_merge(q, rq, &free)) { >> spin_unlock_irq(&bfqd->lock); >> blk_mq_free_requests(&free); >> @@ -6156,6 +6156,7 @@ static void bfq_insert_request(struct blk_mq_hw_ctx *hctx, struct request *rq, >> >> trace_block_rq_insert(rq); >> >> + bfqq = bfq_init_rq(rq); >> if (!bfqq || at_head) { >> if (at_head) >> list_add(&rq->queuelist, &bfqd->dispatch); >> -- >> 2.34.1 >>
> Il giorno 15 ott 2022, alle ore 05:32, Yuwei Guan <ssawgyw@gmail.com> ha scritto: > > > On 2022/10/14 22:50, Jan Kara wrote: >> On Thu 13-10-22 21:53:21, Yuwei Guan wrote: >>> It's useless to do bfq_init_rq(rq), if the rq can do merge first. >>> >>> In the patch 5f550ede5edf8, it moved to bfq_init_rq() before >>> blk_mq_sched_try_insert_merge(), but it's pointless, >>> as the fifo_time of next is not set yet, >>> and !list_empty(&next->queuelist) is 0, so it does not >>> need to reposition rq's fifo_time. >>> >>> And for the "hash lookup, try again" situation, as follow, >>> bfq_requests_merged() call can work normally. >>> >>> blk_mq_sched_try_insert_merge >>> elv_attempt_insert_merge >>> elv_rqhash_find >>> >>> Signed-off-by: Yuwei Guan <Yuwei.Guan@zeekrlife.com> >> OK, after some thinking I agree. How much testing has this patch got? >> Because I'd like to verify we didn't overlook something. >> >> Honza > Thanks for reviewing. > I tested it with fio seq read case like bellow, > then check blk trace and bfq log. > > [global] > name=fio-seq-reads > filename=fio-seq-reads > rw=read > bs=16K > direct=1 > numjobs=4 > > [file1] > size=32m > ioengine=psync > > What kinds of test cases you perfer to do, I will deal with them, > or we verify this patch together, if you have free time. :) Hi guys, thank you Yuwei for proposing this. Yet, I'm a little doubtful, for the case where blk_mq_sched_try_insert_merge returns true, and then to bfq_init_rq() does not get called. In this case, all the code for handling bursts, splits, ioprio changes and the other stuff in to bfq_init_rq() is not executed. This worries me a little bit. Can you show me why not executing these operations is fine? Thanks, Paolo >>> --- >>> block/bfq-iosched.c | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c >>> index 7ea427817f7f..9845370a701c 100644 >>> --- a/block/bfq-iosched.c >>> +++ b/block/bfq-iosched.c >>> @@ -6147,7 +6147,7 @@ static void bfq_insert_request(struct blk_mq_hw_ctx *hctx, struct request *rq, >>> bfqg_stats_update_legacy_io(q, rq); >>> #endif >>> spin_lock_irq(&bfqd->lock); >>> - bfqq = bfq_init_rq(rq); >>> + >>> if (blk_mq_sched_try_insert_merge(q, rq, &free)) { >>> spin_unlock_irq(&bfqd->lock); >>> blk_mq_free_requests(&free); >>> @@ -6156,6 +6156,7 @@ static void bfq_insert_request(struct blk_mq_hw_ctx *hctx, struct request *rq, >>> trace_block_rq_insert(rq); >>> + bfqq = bfq_init_rq(rq); >>> if (!bfqq || at_head) { >>> if (at_head) >>> list_add(&rq->queuelist, &bfqd->dispatch); >>> -- >>> 2.34.1
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 7ea427817f7f..9845370a701c 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -6147,7 +6147,7 @@ static void bfq_insert_request(struct blk_mq_hw_ctx *hctx, struct request *rq, bfqg_stats_update_legacy_io(q, rq); #endif spin_lock_irq(&bfqd->lock); - bfqq = bfq_init_rq(rq); + if (blk_mq_sched_try_insert_merge(q, rq, &free)) { spin_unlock_irq(&bfqd->lock); blk_mq_free_requests(&free); @@ -6156,6 +6156,7 @@ static void bfq_insert_request(struct blk_mq_hw_ctx *hctx, struct request *rq, trace_block_rq_insert(rq); + bfqq = bfq_init_rq(rq); if (!bfqq || at_head) { if (at_head) list_add(&rq->queuelist, &bfqd->dispatch);