LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Paolo Valente <paolo.valente@linaro.org>
To: Yu Kuai <yukuai3@huawei.com>
Cc: axboe@kernel.dk, linux-block@vger.kernel.org,
	linux-kernel@vger.kernel.org, yi.zhang@huawei.com
Subject: Re: [PATCH v2 4/4] block, bfq: consider request size in bfq_asymmetric_scenario()
Date: Thu, 26 Aug 2021 19:00:47 +0200	[thread overview]
Message-ID: <8601F280-2F16-446A-95BA-37A07D1A1055@linaro.org> (raw)
In-Reply-To: <20210806020826.1407257-5-yukuai3@huawei.com>



> Il giorno 6 ago 2021, alle ore 04:08, Yu Kuai <yukuai3@huawei.com> ha scritto:
> 
> There is a special case when bfq do not need to idle when more than
> one groups is active:
> 

Unfortunately, there is a misunderstanding here.  If more than one
group is active, then idling is not needed only if a lot of symmetry
conditions also hold:
- all active groups have the same weight
- all active groups contain the same number of active queues
- all active queues have the same weight
- all active queues belong to the same I/O-priority class
- all dispatched requests have the same size

Similarly, if only one group is active, then idling is not needed only
if the above last three conditions hold.

The current logic, including your changes up to your previous patch,
is simply ignoring the last condition above.

So, unfortunately, your extra information about varied request size
should be used in the opposite way than how you propose to use it.

Thanks,
Paolo

> 1) all active queues have the same weight,
> 2) all active queues have the same request size.
> 3) all active queues belong to the same I/O-priority class,
> 
> Each time a request is dispatched, bfq can switch in service queue
> safely, since the throughput of each active queue is guaranteed to
> be equivalent.
> 
> Test procedure:
> run "fio -numjobs=1 -ioengine=psync -bs=4k -direct=1 -rw=randread..." in
> different cgroup(not root).
> 
> Test result: total bandwidth(Mib/s)
> | total jobs | before this patch | after this patch      |
> | ---------- | ----------------- | --------------------- |
> | 1          | 33.8              | 33.8                  |
> | 2          | 33.8              | 65.4 (32.7 each job)  |
> | 4          | 33.8              | 106.8 (26.7 each job) |
> | 8          | 33.8              | 126.4 (15.8 each job) |
> 
> Signed-off-by: Yu Kuai <yukuai3@huawei.com>
> ---
> block/bfq-iosched.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
> index 7df3fc0ef4ef..e5a07bd1fd84 100644
> --- a/block/bfq-iosched.c
> +++ b/block/bfq-iosched.c
> @@ -268,6 +268,16 @@ static struct kmem_cache *bfq_pool;
>  */
> #define BFQ_RATE_SHIFT		16
> 
> +/*
> + * 1) bfq keep dispatching requests with same size for at least one second.
> + * 2) bfq dispatch at lease 1024 requests
> + *
> + * We think bfq are dispatching request with same size if the above two
> + * conditions hold true.
> + */
> +#define VARIED_REQUEST_SIZE(bfqd) ((bfqd)->dispatch_count < 1024 ||\
> +		time_before(jiffies, (bfqd)->dispatch_time + HZ))
> +
> /*
>  * When configured for computing the duration of the weight-raising
>  * for interactive queues automatically (see the comments at the
> @@ -724,7 +734,8 @@ static bool bfq_asymmetric_scenario(struct bfq_data *bfqd,
> 	bool multiple_classes_busy;
> 
> #ifdef CONFIG_BFQ_GROUP_IOSCHED
> -	if (bfqd->num_groups_with_pending_reqs > 1)
> +	if (bfqd->num_groups_with_pending_reqs > 1 &&
> +	    VARIED_REQUEST_SIZE(bfqd))
> 		return true;
> 
> 	if (bfqd->num_groups_with_pending_reqs &&
> -- 
> 2.31.1
> 


  reply	other threads:[~2021-08-26 17:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-06  2:08 [PATCH v2 0/4] optimize the bfq queue idle judgment Yu Kuai
2021-08-06  2:08 ` [PATCH v2 1/4] block, bfq: add support to track if root_group have any pending requests Yu Kuai
2021-08-26 17:00   ` Paolo Valente
2021-09-02 13:23     ` yukuai (C)
2021-08-06  2:08 ` [PATCH v2 2/4] block, bfq: do not idle if only one cgroup is activated Yu Kuai
2021-08-26 17:00   ` Paolo Valente
2021-09-02 13:31     ` yukuai (C)
2021-09-07  9:10       ` Paolo Valente
2021-09-07 11:19         ` yukuai (C)
2021-08-06  2:08 ` [PATCH v2 3/4] block, bfq: add support to record request size information Yu Kuai
2021-08-26 17:00   ` Paolo Valente
2021-08-06  2:08 ` [PATCH v2 4/4] block, bfq: consider request size in bfq_asymmetric_scenario() Yu Kuai
2021-08-26 17:00   ` Paolo Valente [this message]
2021-09-07 11:29     ` yukuai (C)
2021-09-15  7:36       ` Paolo Valente
2021-09-15  7:47         ` yukuai (C)
2021-08-14  2:34 ` [PATCH v2 0/4] optimize the bfq queue idle judgment yukuai (C)
2021-08-24 14:09   ` yukuai (C)
2021-08-26 16:59 ` Paolo Valente

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8601F280-2F16-446A-95BA-37A07D1A1055@linaro.org \
    --to=paolo.valente@linaro.org \
    --cc=axboe@kernel.dk \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai3@huawei.com \
    --subject='Re: [PATCH v2 4/4] block, bfq: consider request size in bfq_asymmetric_scenario()' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).