Re: [PATCH 01/32] btrfs: extent_io: remove the extent_start/extent_len for end_bio_extent_readpage()

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2020/11/6 上午10:01, Qu Wenruo wrote:
> ...
>>
>> Can't answer that without quantifying what the performance impact is so
>> we can properly judge complexity/performance trade-off!
>> First I'd like to have numbers showing what the overhead otherwise it
>> will be impossible to tell if whatever approach you choose brings any
>> improvements.
>
> You and Josef are right. The too many extra extent io tree call is
> greatly hammering the performance of endio function.
>
> Just a very basic average execution time around that part shows obvious
> performance drop (read 1GiB file):
>
> BEFORE: (Execution time between the page_unlock() and the end of the loop)
> total_time=117795112ns nr_events=262144
> avg=449.35ns
>
> AFTER: (execution time for the two functions at the end of the loop)
> total_time=3058216317ns nr_events=262144
> avg=11666.17ns
>
> So, definitely NACK.
>
> I'll switch back to the old behavior, but still try to enhance its
> readability.
>

Base on this result, a lot of subpage work needs to be re-done.

This shows that, although extent io tree operation can replace some page
status in functionality, the performance is still way worse than page bits.

I guess that's also why iomap uses bitmap for each subpage, not some
btree based global status tracking.
Meaning later new EXTENT_* bits for data is going to cause the same
performance impact.

Now I have to change the policy to how to attack the data read write
path. Since bit map is unavoidable, then it looks like waiting for iomap
integration is no longer a feasible solution for subpage support.

A similar bitmap needs to be implemented inside btrfs first, allowing
full subpage read/write ability, then switch to iomap afterwards.

The next update may be completely different then.

Thanks,
Qu