From: mingzhe <mingzhe.zou@easystack.cn>
To: Coly Li <colyli@suse.de>, linux-bcache@vger.kernel.org
Cc: zoumingzhe@qq.com
Subject: Re: [PATCH v2] bcache: fix set_at_max_writeback_rate() for multiple attached devices
Date: Mon, 19 Sep 2022 11:29:40 +0800 [thread overview]
Message-ID: <6d8a2888-b20a-c71c-733f-97c6a91f1244@easystack.cn> (raw)
In-Reply-To: <20220918121647.103458-1-colyli@suse.de>
在 2022/9/18 20:16, Coly Li 写道:
> Inside set_at_max_writeback_rate() the calculation in following if()
> check is wrong,
> if (atomic_inc_return(&c->idle_counter) <
> atomic_read(&c->attached_dev_nr) * 6)
>
> Because each attached backing device has its own writeback thread
> running and increasing c->idle_counter, the counter increates much
> faster than expected. The correct calculation should be,
> (counter / dev_nr) < dev_nr * 6
> which equals to,
> counter < dev_nr * dev_nr * 6
>
> This patch fixes the above mistake with correct calculation, and helper
> routine idle_counter_exceeded() is added to make code be more clear.
>
> Reported-by: Mingzhe Zou <mingzhe.zou@easystack.cn>
> Signed-off-by: Coly Li <colyli@suse.de>
> ---
> Changelog:
> v2: Add the missing "!atomic_read(&c->at_max_writeback_rate)" part
> back.
> v1: Original verison.
>
> drivers/md/bcache/writeback.c | 73 +++++++++++++++++++++++++----------
> 1 file changed, 52 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/md/bcache/writeback.c b/drivers/md/bcache/writeback.c
> index 647661005176..c186bf55fe61 100644
> --- a/drivers/md/bcache/writeback.c
> +++ b/drivers/md/bcache/writeback.c
> @@ -157,6 +157,53 @@ static void __update_writeback_rate(struct cached_dev *dc)
> dc->writeback_rate_target = target;
> }
>
> +static bool idle_counter_exceeded(struct cache_set *c)
> +{
> + int counter, dev_nr;
> +
> + /*
> + * If c->idle_counter is overflow (idel for really long time),
> + * reset as 0 and not set maximum rate this time for code
> + * simplicity.
> + */
> + counter = atomic_inc_return(&c->idle_counter);
> + if (counter <= 0) {
> + atomic_set(&c->idle_counter, 0);
> + return false;
> + }
> +
> + dev_nr = atomic_read(&c->attached_dev_nr);
> + if (dev_nr == 0)
> + return false;
> +
> + /*
> + * c->idle_counter is increased by writeback thread of all
> + * attached backing devices, in order to represent a rough
> + * time period, counter should be divided by dev_nr.
> + * Otherwise the idle time cannot be larger with more backing
> + * device attached.
> + * The following calculation equals to checking
> + * (counter / dev_nr) < (dev_nr * 6)
> + */
> + if (counter < (dev_nr * dev_nr * 6))
> + return false;
Hi, Coly
Look good to me. However, do we need to specify a maximum value for
idle_counter. If cache_set has 100 backing devices, there are dev_nr*6
rounds of update_writeback_rate() on each backing device, which takes
dc->writeback_rate_update_seconds(default is 5 seconds)*600 seconds.
In fact, any io request from the backing device will clear the
idle_counter of cache_set, and at_max_writeback_rate will exit soon.
Therefore, if cache_set waits for 5 minutes or 10 minutes without any io
request to start at_max_writeback_rate, it will not have any effect on
the possible front-end io.
In addition, cache_set only waits 6 rounds of update_writeback_rate()
should not have much performance impact.
mingzhe
> +
> + return true;
> +}
> +
> +/*
> + * Idle_counter is increased everytime when update_writeback_rate() is
> + * called. If all backing devices attached to the same cache set have
> + * identical dc->writeback_rate_update_seconds values, it is about 6
> + * rounds of update_writeback_rate() on each backing device before
> + * c->at_max_writeback_rate is set to 1, and then max wrteback rate set
> + * to each dc->writeback_rate.rate.
> + * In order to avoid extra locking cost for counting exact dirty cached
> + * devices number, c->attached_dev_nr is used to calculate the idle
> + * throushold. It might be bigger if not all cached device are in write-
> + * back mode, but it still works well with limited extra rounds of
> + * update_writeback_rate().
> + */
> static bool set_at_max_writeback_rate(struct cache_set *c,
> struct cached_dev *dc)
> {
> @@ -167,21 +214,8 @@ static bool set_at_max_writeback_rate(struct cache_set *c,
> /* Don't set max writeback rate if gc is running */
> if (!c->gc_mark_valid)
> return false;
> - /*
> - * Idle_counter is increased everytime when update_writeback_rate() is
> - * called. If all backing devices attached to the same cache set have
> - * identical dc->writeback_rate_update_seconds values, it is about 6
> - * rounds of update_writeback_rate() on each backing device before
> - * c->at_max_writeback_rate is set to 1, and then max wrteback rate set
> - * to each dc->writeback_rate.rate.
> - * In order to avoid extra locking cost for counting exact dirty cached
> - * devices number, c->attached_dev_nr is used to calculate the idle
> - * throushold. It might be bigger if not all cached device are in write-
> - * back mode, but it still works well with limited extra rounds of
> - * update_writeback_rate().
> - */
> - if (atomic_inc_return(&c->idle_counter) <
> - atomic_read(&c->attached_dev_nr) * 6)
> +
> + if (!idle_counter_exceeded(c))
> return false;
>
> if (atomic_read(&c->at_max_writeback_rate) != 1)
> @@ -195,13 +229,10 @@ static bool set_at_max_writeback_rate(struct cache_set *c,
> dc->writeback_rate_change = 0;
>
> /*
> - * Check c->idle_counter and c->at_max_writeback_rate agagain in case
> - * new I/O arrives during before set_at_max_writeback_rate() returns.
> - * Then the writeback rate is set to 1, and its new value should be
> - * decided via __update_writeback_rate().
> + * In case new I/O arrives during before
> + * set_at_max_writeback_rate() returns.
> */
> - if ((atomic_read(&c->idle_counter) <
> - atomic_read(&c->attached_dev_nr) * 6) ||
> + if (!idle_counter_exceeded(c) ||
> !atomic_read(&c->at_max_writeback_rate))
> return false;
>
next prev parent reply other threads:[~2022-09-19 3:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-18 12:16 [PATCH v2] bcache: fix set_at_max_writeback_rate() for multiple attached devices Coly Li
2022-09-19 3:29 ` mingzhe [this message]
2022-09-19 4:38 ` Coly Li
2022-09-19 6:24 ` mingzhe
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=6d8a2888-b20a-c71c-733f-97c6a91f1244@easystack.cn \
--to=mingzhe.zou@easystack.cn \
--cc=colyli@suse.de \
--cc=linux-bcache@vger.kernel.org \
--cc=zoumingzhe@qq.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox