public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Boris Burkov <boris@bur.io>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org, Josef Bacik <josef@toxicpanda.com>
Subject: Re: [PATCH 0/3] btrfs: make subpage reader/writer counter to be sector aware
Date: Wed, 14 Feb 2024 10:21:17 -0800	[thread overview]
Message-ID: <20240214182117.GA377066@zen.localdomain> (raw)
In-Reply-To: <cover.1707883446.git.wqu@suse.com>

On Wed, Feb 14, 2024 at 02:34:33PM +1030, Qu Wenruo wrote:
> This can be fetched from github, and the branch would be utilized for
> all newer subpage delalloc update to support full sector sized
> compression and zoned:
> https://github.com/adam900710/linux/tree/subpage_delalloc
> 
> Currently we just trace subpage reader/writer counter using an atomic.
> 
> It's fine for the current subpage usage, but for the future, we want to
> be aware of which subpage sector is locked inside a page, for proper
> compression (we only support full page compression for now) and zoned support.

The logic of the patches seems good and self-consistent to me, I don't
see any issues.

However, I think it would be helpful to at least see the client code to
motivate the bitmap a bit more for the ignorant :)

Also, from a semi-cursory inspection, it looks like this relies on
extent locking to ensure that multiple threads don't collide on the
subpage bitmap, is that correct? You should check with Josef that his
plans with getting rid of the extent locking don't clash with this.

Thanks,
Boris

> 
> So here we introduce a new bitmap, called locked bitmap, to trace which
> sector is locked for read/write.
> 
> And since reader/writer are both exclusive (to each other and to the same
> type of lock), we can safely use the same bitmap for both reader and
> writer.
> 
> In theory we can use the bitmap (the weight of the locked bitmap) to
> indicate how many bytes are under reader/write lock, but it's not
> possible yet:
> 
> - No weight support for bitmap range
>   The bitmap API only provides bitmap_weight(), which always starts at
>   bit 0.
> 
> - Need to distinguish read/write lock
> 
> Thus we still keep the reader/writer atomic counter.
> 
> Qu Wenruo (3):
>   btrfs: unexport btrfs_subpage_start_writer() and
>     btrfs_subpage_end_and_test_writer()
>   btrfs: subpage: make reader lock to utilize bitmap
>   btrfs: subpage: make writer lock to utilize bitmap
> 
>  fs/btrfs/subpage.c | 70 ++++++++++++++++++++++++++++++++++++----------
>  fs/btrfs/subpage.h | 16 +++++++----
>  2 files changed, 66 insertions(+), 20 deletions(-)
> 
> -- 
> 2.43.1
> 

  parent reply	other threads:[~2024-02-14 18:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-14  4:04 [PATCH 0/3] btrfs: make subpage reader/writer counter to be sector aware Qu Wenruo
2024-02-14  4:04 ` [PATCH 1/3] btrfs: unexport btrfs_subpage_start_writer() and btrfs_subpage_end_and_test_writer() Qu Wenruo
2024-02-14  4:04 ` [PATCH 2/3] btrfs: subpage: make reader lock to utilize bitmap Qu Wenruo
2024-02-14  4:04 ` [PATCH 3/3] btrfs: subpage: make writer " Qu Wenruo
2024-02-14 18:21 ` Boris Burkov [this message]
2024-02-14 21:09   ` [PATCH 0/3] btrfs: make subpage reader/writer counter to be sector aware Qu Wenruo
2024-02-14 21:25     ` Boris Burkov
2024-02-14 21:33       ` Qu Wenruo

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=20240214182117.GA377066@zen.localdomain \
    --to=boris@bur.io \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.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