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

[Qu Wenruo <wqu@suse.com>]

在 2024/2/22 22:24, David Sterba 写道:
> 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.

Got it.

BTW, this series is only stable enough after testing the whole series 
(so that no new extra changes required by later subpage delalloc behavior),
which ran fine locally at least.