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. > > 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. <snip>
