Chris Murphy wrote on Mon, Jan 24, 2022 at 02:56:09PM -0700:
> Should be true, and if this nspawn container is running on the host
> then they should share the same btrfs file system. And even if nspawn
> is creating separate subvolumes for the mock build (?not sure if it
> does) then because it's a nested subvolume, not mounted, there's no
> mount point boundary to cross so you *do* get reflink copies between
> subvolumes.
For what it's worth the example given does renames in the same directory
(since that's what rpm does when installing things anyway), so there is
no reflink involved, just a plain rename call
I got curious so I tried reproducing but unfortunately I get similar
times whether it's in mock or native, but it varies from a run to
another.
Running with perf record -g, I get the following hog:
- 95.11% 0.01% mv [kernel.kallsyms] [k] entry_SYSCALL_64_after_hwframe
95.10% entry_SYSCALL_64_after_hwframe
- do_syscall_64
- 92.40% __x64_sys_renameat2
- 92.40% do_renameat2
- 92.36% vfs_rename
- 92.34% btrfs_rename2
- 92.09% btrfs_log_new_name
- btrfs_log_inode_parent
- 53.42% log_new_dir_dentries
- 47.27% btrfs_log_inode
+ 13.78% btrfs_log_all_xattrs
+ 11.60% copy_items.isra.0
+ 11.58% drop_objectid_items
+ 4.31% btrfs_search_forward
+ 2.39% btrfs_search_slot
1.21% btrfs_release_path
+ 1.00% btrfs_commit_inode_delayed_inode
+ 2.26% btrfs_search_forward
+ 1.04% btrfs_iget
0.89% read_extent_buffer
- 38.65% btrfs_log_inode
- 38.41% log_directory_changes
- log_dir_items
- 35.01% overwrite_item
+ 19.04% btrfs_search_slot
+ 3.59% btrfs_release_path
+ 3.32% kfree
3.07% __kmalloc
2.84% read_extent_buffer
1.40% btrfs_get_32
0.63% memcmp
1.67% read_extent_buffer
So basically the directory modification is costly for each rename and it
doesn't seem to get batched, maybe that would give a hint as to
somewhere that could be improved.
(I wasn't able to reliably produce the slightly shorter times I got to
check with perf record, but I did get one run with ~20s when it's
usually much longer so there's probably something... Never went as far
down as sub-10s though)
--
Dominique
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
