Re: [PATCH v2] btrfs: speedup mount time with readahead chunk tree

["Holger Hoffstätte" <holger@applied-asynchrony.com>]

On 2020-07-08 16:04, David Sterba wrote:
> On Wed, Jul 08, 2020 at 10:19:22AM +0800, Robbie Ko wrote:
>> David Sterba 於 2020/7/8 上午3:25 寫道:
>>> On Tue, Jul 07, 2020 at 11:59:44AM +0800, robbieko wrote:
>>>> From: Robbie Ko <robbieko@synology.com>
>>>>
>>>> When mounting, we always need to read the whole chunk tree,
>>>> when there are too many chunk items, most of the time is
>>>> spent on btrfs_read_chunk_tree, because we only read one
>>>> leaf at a time.
>>>>
>>>> It is unreasonable to limit the readahead mechanism to a
>>>> range of 64k, so we have removed that limit.
>>>>
>>>> In addition we added reada_maximum_size to customize the
>>>> size of the pre-reader, The default is 64k to maintain the
>>>> original behavior.
>>>>
>>>> So we fix this by used readahead mechanism, and set readahead
>>>> max size to ULLONG_MAX which reads all the leaves after the
>>>> key in the node when reading a level 1 node.
>>> The readahead of chunk tree is a special case as we know we will need
>>> the whole tree, in all other cases the search readahead needs is
>>> supposed to read only one leaf.
>>
>> If, in most cases, readahead requires that only one leaf be read, then
>> reada_ maximum_size should be nodesize instead of 64k, or use
>> reada_maximum_ nr (default:1) seems better.
>>
>>>
>>> For that reason I don't want to touch the current path readahead logic
>>> at all and do the chunk tree readahead in one go instead of the
>>> per-search.
>>
>> I don't know why we don't make the change to readahead, because the current
>> readahead is limited to the logical address in 64k is very unreasonable,
>> and there is a good chance that the logical address of the next leaf
>> node will
>> not appear in 64k, so the existing readahead is almost useless.
> 
> I see and it seems that the assumption about layout and chances
> succesfuly read blocks ahead is not valid. The logic of readahead could
> be improved but that would need more performance evaluation.

FWIW I gave this a try and see the following numbers, averaged over multiple
mount/unmount cycles on spinning rust:

without patch : ~2.7s
with patch    : ~4.5s

..ahem..

-h