From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 0/3] btrfs: make subpage reader/writer counter to be sector aware
Date: Sat, 17 Feb 2024 16:59:47 +1030 [thread overview]
Message-ID: <cover.1708151123.git.wqu@suse.com> (raw)
[CHANGELOG]
v2:
- Add btrfs_subpage_dump_bitmap() support for locked bitmap
- Add spinlock to protect the bitmap and locked bitmap operation
In theory, this opeartion should always be single threaded, since the
page is locked.
But to keep the behavior consistent, use spin lock to protect bitmap
and atomic reader/write updates.
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.
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 | 77 ++++++++++++++++++++++++++++++++++++----------
fs/btrfs/subpage.h | 16 +++++++---
2 files changed, 72 insertions(+), 21 deletions(-)
--
2.43.1
next reply other threads:[~2024-02-17 6:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-17 6:29 Qu Wenruo [this message]
2024-02-17 6:29 ` [PATCH v2 1/3] btrfs: unexport btrfs_subpage_start_writer() and btrfs_subpage_end_and_test_writer() Qu Wenruo
2024-02-17 6:29 ` [PATCH v2 2/3] btrfs: subpage: make reader lock to utilize bitmap Qu Wenruo
2024-02-17 6:29 ` [PATCH v2 3/3] btrfs: subpage: make writer " Qu Wenruo
2024-02-22 11:54 ` [PATCH v2 0/3] btrfs: make subpage reader/writer counter to be sector aware David Sterba
2024-02-22 20:34 ` 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=cover.1708151123.git.wqu@suse.com \
--to=wqu@suse.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