Re: [PATCH v2 0/3] btrfs: make subpage reader/writer counter to be sector aware

[David Sterba <dsterba@suse.cz>]

On Sat, Feb 17, 2024 at 04:59:47PM +1030, Qu Wenruo wrote:
> [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

So this is preparatory work and looks safe to me, only adding the
bitmaps to counters, you can add it to for-next.