Now with a little larger fs (257G used, backed by HDD), the result is much more obvious:
$ sudo perf ftrace -t function_graph \ -T open_ctree \ -T btrfs_read_block_groups \ -T check_chunk_block_group_mappings \ -T btrfs_read_chunk_tree \ -T btrfs_verify_dev_extents \ mount /dev/vdc /mnt/btrfs/ 3) | open_ctree [btrfs]() { 3) | btrfs_read_chunk_tree [btrfs]() { 3) * 69033.31 us | } 3) | btrfs_verify_dev_extents [btrfs]() { 3) * 90376.15 us | } 3) | btrfs_read_block_groups [btrfs]() { 2) $ 2733853 us | } /* btrfs_read_block_groups [btrfs] */ 2) $ 3168384 us | } /* open_ctree [btrfs] */ For btrfs_read_chunk_tree() and btrfs_verify_dev_extents(), combined they take less than 160ms. While for btrfs_read_block_groups() it take 2.7s while the total mount time is 3.1s, meaning btrfs_read_block_groups() is already taking 87% of the mount time. I'll try to make btrfs BLOCK_GROUP_ITEM into one separate tree to make they iterate just like chunks tree, and see how it will end up. Thanks, Qu On 2018/12/20 下午1:47, Qu Wenruo wrote: > > > On 2018/12/5 下午2:55, Nikolay Borisov wrote: >> >> >> On 4.12.18 г. 22:14 ч., Wilson, Ellis wrote: >> >> A command that would be good is : >> >> perf record --all-kernel -g mount /dev/vdc /media/scratch/ > > > In fact, if we're just going to verify if it's btrfs_read_block_groups() > causing the biggest problem, we could use ftrace directly (wrapped by > "perf ftrace"): > > perf ftrace -t function_graph -T open_ctree \ > -T btrfs_read_block_groups \ > mount $dev $mnt > > The result will be super easy to read, something like: > > 2) | open_ctree [btrfs]() { > 2) | btrfs_read_block_groups [btrfs]() { > 2) # 1726.598 us | } > 2) * 21817.28 us | } > > > Since I'm just using a small fs, with 4G data copied from /usr, we won't > populate extent tree with enough backrefs, thus > btrfs_read_block_groups() won't be a big problem. (only 7.9%) > > However when I populate the fs with small inline files along with small > data extents, and 4K nodesize to bump up extent tree size, the same 4G > data would result a different story: > > 3) | open_ctree [btrfs]() { > 3) | btrfs_read_block_groups [btrfs]() { > 3) # 4567.645 us | } > 3) * 22520.95 us | } > > Now it's 20.3% of the total mount time. > I believe the percentage will just increase and go over 70% when the fs > is larger and larger. > > > So, Wilson, would you please use above "perf ftrace" command to get the > function duration? > > Thanks, > Qu > >> >> of course replace device/mount path appropriately. This will result in a >> perf.data file which contains stacktraces of the hottest paths executed >> during invocation of mount. If you could send this file to the mailing >> list or upload it somwhere for interested people (me and perhaps) Qu to >> inspect would be appreciated. >> >> If the file turned out way too big you can use >> >> perf report --stdio to create a text output and you could send that as >> well.