On 2018/10/9 上午6:41, Chris Murphy wrote: > [chris@flap ~]$ sudo perf stat -e 'btrfs:*' -a sleep 70 > ##And then I loaded a few sites in Firefox early on in those 70 seconds. > > Performance counter stats for 'system wide': > > 5 btrfs:btrfs_transaction_commit > 29 btrfs:btrfs_inode_new > 29 btrfs:btrfs_inode_request > 25 btrfs:btrfs_inode_evict > 1,602 btrfs:btrfs_get_extent > 0 btrfs:btrfs_handle_em_exist > 1 btrfs:btrfs_get_extent_show_fi_regular > 88 btrfs:btrfs_truncate_show_fi_regular > 19 btrfs:btrfs_get_extent_show_fi_inline > 2 btrfs:btrfs_truncate_show_fi_inline > 189 btrfs:btrfs_ordered_extent_add > 189 btrfs:btrfs_ordered_extent_remove > 9 btrfs:btrfs_ordered_extent_start > 592 btrfs:btrfs_ordered_extent_put > 1,207 btrfs:__extent_writepage > 1,203 btrfs:btrfs_writepage_end_io_hook > 25 btrfs:btrfs_sync_file > 0 btrfs:btrfs_sync_fs > 0 btrfs:btrfs_add_block_group > 1,508 btrfs:add_delayed_tree_ref > 1,498 btrfs:run_delayed_tree_ref > 379 btrfs:add_delayed_data_ref > 336 btrfs:run_delayed_data_ref > 1,887 btrfs:add_delayed_ref_head > 1,839 btrfs:run_delayed_ref_head > 0 btrfs:btrfs_chunk_alloc > 0 btrfs:btrfs_chunk_free > 794 btrfs:btrfs_cow_block > 6,982 btrfs:btrfs_space_reservation > 0 btrfs:btrfs_trigger_flush > 0 btrfs:btrfs_flush_space > 952 btrfs:btrfs_reserved_extent_alloc > 0 btrfs:btrfs_reserved_extent_free > 1,005 btrfs:find_free_extent > 1,005 btrfs:btrfs_reserve_extent > 816 btrfs:btrfs_reserve_extent_cluster > 1 btrfs:btrfs_find_cluster > 0 btrfs:btrfs_failed_cluster_setup > 1 btrfs:btrfs_setup_cluster > 5,952 btrfs:alloc_extent_state > 6,034 btrfs:free_extent_state > 374 btrfs:btrfs_work_queued > 362 btrfs:btrfs_work_sched > 362 btrfs:btrfs_all_work_done > 116 btrfs:btrfs_ordered_sched > 0 btrfs:btrfs_workqueue_alloc > 0 btrfs:btrfs_workqueue_destroy > 0 btrfs:btrfs_qgroup_reserve_data > 201 btrfs:btrfs_qgroup_release_data > 1,839 btrfs:btrfs_qgroup_free_delayed_ref > 0 btrfs:btrfs_qgroup_account_extents > 0 btrfs:btrfs_qgroup_trace_extent > 0 btrfs:btrfs_qgroup_account_extent > 0 btrfs:qgroup_update_counters > 0 btrfs:qgroup_update_reserve > 0 btrfs:qgroup_meta_reserve > 0 btrfs:qgroup_meta_convert > 0 btrfs:qgroup_meta_free_all_pertrans > 0 btrfs:btrfs_prelim_ref_merge > 0 btrfs:btrfs_prelim_ref_insert > 2,663 btrfs:btrfs_inode_mod_outstanding_extents > 0 btrfs:btrfs_remove_block_group > 0 btrfs:btrfs_add_unused_block_group > 0 btrfs:btrfs_skip_unused_block_group > > 70.004723586 seconds time elapsed > > [chris@flap ~]$ > > > Seems like a lot of activity for just a few transactions, but what > really caught my eye here is the qgroup reporting for a file system > that has never had qgroups enabled. Is it expected?
Indeed some of them can be avoided, as for qgroup not enabled case, such function is really doing nothing. In the case of btrfs_qgroup_free_delayed_ref() case, it doesn't check if qgroup is enabled and calls btrfs_qgroup_free_refroot() under all cases, and expect btrfs_qgroup_free_refroot() to do some check. However btrfs_qgroup_free_refroot() doesn't do any check on if qgroup is enabled or not. And btrfs_qgroup_free_refroot() will just find no corresponding qgroup and exit. Thanks for exposing such bug, Qu > > > Chris Murphy >
signature.asc
Description: OpenPGP digital signature
