Nikolay Borisov 於 2020/7/6 下午4:37 寫道:
On 6.07.20 г. 11:28 ч., Qu Wenruo wrote:
On 2020/7/6 下午4:05, Robbie Ko wrote:
I've known btrfs_read_block_groups for a long time,
we can use BG_TREE freature to speed up btrfs_read_block_groups.
https://lwn.net/Articles/801990/
But reading the chunk tree also takes some time,
we can speed up the chunk tree by using the readahead mechanism.
Why we not just use regular forward readahead?
- Because the regular forward readahead ,
reads only the logical address adjacent to the 64k,
but the logical address of the next leaf may not be in 64k.
Great, please add these into the changelog for the need of
READA_FORWARD_FORCE.
<nod> Performance patches should come with data backing their
performance improvements claims.
Ok, I will add these into the changelog.
But on the other hand, it looks like we could change READA_FORWARD
without introducing the _FORCE version,
as _FORCE variant is what we really want.
That logical bytenr limit looks not reasonable to me, which makes that
READA_FORWARD near useless to me.
Although in that direction, we also need to verify all existing
READA_FORWARD are really correctly.
Personally I tend to prefer change existing READA_FORWARD and review all
existing callers.
I agree, we should ideally revise the existing READA_FORWARD and give it
better semantics if the current ones are needlessly rigid. Only if this
improves way too cumbersome i.e breaking assumption which are made
should we introduce yet another mode. Because this other mode is really
just special casing and we should avoid special cases as much as possible.
Ok, I'll modify the existing READA_FORWARD mechanism to make it better
and send a V2 patch.
<snip>
