From: Pavel Begunkov <asml.silence@gmail.com>
To: Amy Parker <enbyamy@gmail.com>
Cc: Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 2/4] btrfs: discard: save discard delay as ns not jiffy
Date: Wed, 4 Nov 2020 15:48:23 +0000 [thread overview]
Message-ID: <bcd88bb1-37e6-2b1d-6fe8-390d3aa68d29@gmail.com> (raw)
In-Reply-To: <CAE1WUT5k8e_twhb8yZX7=kYFX-ikzUuQwunRkPCCH-zJ80Q6TA@mail.gmail.com>
On 04/11/2020 15:35, Amy Parker wrote:
> On Wed, Nov 4, 2020 at 1:52 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
>>
>> Most of calculations are done in ns or ms, so store discard_ctl->delay
>> in ms and convert the final delay to jiffies only in the end.
>
> Great idea.
>
>>
>> Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
>> ---
>> fs/btrfs/ctree.h | 2 +-
>> fs/btrfs/discard.c | 14 +++++++-------
>> 2 files changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
>> index aac3d6f4e35b..d43a82dcdfc0 100644
>> --- a/fs/btrfs/ctree.h
>> +++ b/fs/btrfs/ctree.h
>> @@ -472,7 +472,7 @@ struct btrfs_discard_ctl {
>> atomic_t discardable_extents;
>> atomic64_t discardable_bytes;
>> u64 max_discard_size;
>> - unsigned long delay;
>> + u64 delay_ms;
>
> Thanks for converting this from the ambiguous unsigned long to the
> more specific u64.
>
>> u32 iops_limit;
>> u32 kbps_limit;
>> u64 discard_extent_bytes;
>> diff --git a/fs/btrfs/discard.c b/fs/btrfs/discard.c
>> index 76796a90e88d..b6c68e5711f0 100644
>> --- a/fs/btrfs/discard.c
>> +++ b/fs/btrfs/discard.c
>> @@ -355,7 +355,7 @@ void btrfs_discard_schedule_work(struct btrfs_discard_ctl *discard_ctl,
>>
>> block_group = find_next_block_group(discard_ctl, now);
>> if (block_group) {
>> - unsigned long delay = discard_ctl->delay;
>> + u64 delay = discard_ctl->delay_ms * NSEC_PER_MSEC;
>
> I worry about a potential performance impact with this, but it should be
> minimal at most.
That's nothing, nsecs_to_jiffies() in the end is heavier, but this is not
in a hot path and by all means it's heavily amortised by actual discarding.
>
>> u32 kbps_limit = READ_ONCE(discard_ctl->kbps_limit);
>>
>> /*
>> @@ -366,9 +366,9 @@ void btrfs_discard_schedule_work(struct btrfs_discard_ctl *discard_ctl,
>> if (kbps_limit && discard_ctl->prev_discard) {
>> u64 bps_limit = ((u64)kbps_limit) * SZ_1K;
>> u64 bps_delay = div64_u64(discard_ctl->prev_discard *
>> - MSEC_PER_SEC, bps_limit);
>> + NSEC_PER_SEC, bps_limit);
>>
>> - delay = max(delay, msecs_to_jiffies(bps_delay));
>> + delay = max(delay, bps_delay);
>
> Great that we got this down to just passing max() a value. Same thing on
> the instance below.
>
>> }
>>
>> /*
>> @@ -378,11 +378,11 @@ void btrfs_discard_schedule_work(struct btrfs_discard_ctl *discard_ctl,
>> if (now < block_group->discard_eligible_time) {
>> u64 bg_timeout = block_group->discard_eligible_time - now;
>>
>> - delay = max(delay, nsecs_to_jiffies(bg_timeout));
>> + delay = max(delay, bg_timeout);
>> }
>>
>> mod_delayed_work(discard_ctl->discard_workers,
>> - &discard_ctl->work, delay);
>> + &discard_ctl->work, nsecs_to_jiffies(delay));
>> }
>> out:
>> spin_unlock(&discard_ctl->lock);
>> @@ -555,7 +555,7 @@ void btrfs_discard_calc_delay(struct btrfs_discard_ctl *discard_ctl)
>>
>> delay = clamp(delay, BTRFS_DISCARD_MIN_DELAY_MSEC,
>> BTRFS_DISCARD_MAX_DELAY_MSEC);
>> - discard_ctl->delay = msecs_to_jiffies(delay);
>> + discard_ctl->delay_ms = delay;
>>
>> spin_unlock(&discard_ctl->lock);
>> }
>> @@ -687,7 +687,7 @@ void btrfs_discard_init(struct btrfs_fs_info *fs_info)
>> atomic_set(&discard_ctl->discardable_extents, 0);
>> atomic64_set(&discard_ctl->discardable_bytes, 0);
>> discard_ctl->max_discard_size = BTRFS_ASYNC_DISCARD_DEFAULT_MAX_SIZE;
>> - discard_ctl->delay = BTRFS_DISCARD_MAX_DELAY_MSEC;
>> + discard_ctl->delay_ms = BTRFS_DISCARD_MAX_DELAY_MSEC;
>> discard_ctl->iops_limit = BTRFS_DISCARD_MAX_IOPS;
>> discard_ctl->kbps_limit = 0;
>> discard_ctl->discard_extent_bytes = 0;
>> --
>> 2.24.0
>>
>
> Looks all fine to me.
--
Pavel Begunkov
next prev parent reply other threads:[~2020-11-04 15:51 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-04 9:45 [PATCH 0/4] fixes for btrfs async discards Pavel Begunkov
2020-11-04 9:45 ` [PATCH 1/4] btrfs: discard: speed up discard up to iops_limit Pavel Begunkov
2020-11-04 15:29 ` Amy Parker
2020-11-04 17:19 ` Pavel Begunkov
2020-11-04 17:33 ` Amy Parker
2020-11-04 17:47 ` Pavel Begunkov
2020-11-04 17:55 ` Amy Parker
2020-11-04 18:06 ` Pavel Begunkov
2020-11-04 18:14 ` Amy Parker
2020-11-04 20:52 ` Josef Bacik
2020-11-04 9:45 ` [PATCH 2/4] btrfs: discard: save discard delay as ns not jiffy Pavel Begunkov
2020-11-04 15:35 ` Amy Parker
2020-11-04 15:48 ` Pavel Begunkov [this message]
2020-11-04 16:46 ` Amy Parker
2020-11-04 20:54 ` Josef Bacik
2020-11-04 9:45 ` [PATCH 3/4] btrfs: don't miss discards after override-schedule Pavel Begunkov
2020-11-04 20:59 ` Josef Bacik
2020-11-04 21:23 ` Pavel Begunkov
2020-11-04 9:45 ` [PATCH 4/4] btrfs: discard: reschedule work after param update Pavel Begunkov
2020-11-04 21:00 ` Josef Bacik
2020-11-05 22:23 ` [PATCH 0/4] fixes for btrfs async discards David Sterba
2020-11-06 13:20 ` Pavel Begunkov
2020-11-06 13:56 ` David Sterba
2020-11-06 14:19 ` Chris Mason
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=bcd88bb1-37e6-2b1d-6fe8-390d3aa68d29@gmail.com \
--to=asml.silence@gmail.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=enbyamy@gmail.com \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).