https://bugzilla.kernel.org/show_bug.cgi?id=217965 --- Comment #31 from Ojaswin Mujoo (ojaswin.mujoo@xxxxxxx) --- Hey Eyal, Thanks for running the tests. So it definitely feels that there is something going on in the ext4 allocator side. Ideally we shouldn't be taking this much time in finding blocks in the FS especially since the older kernels complete it quickly so it couldn't be a low FS space issue. I spent some good amount of time today trying to replicate it to no avail hence I'll have to request you for some more data. Thanks to the perf report you've shared I have an idea of some kernel areas we can probe to understand whats truly going on. I'll just share the perf probe and perf record commands below. Please let me know if its not possible to run these on the affected distro so we can think of some other way :) ** Adding probe points ** sudo perf probe -a "ext4_mb_find_good_group_avg_frag_lists order" sudo perf probe -a "ext4_mb_find_good_group_avg_frag_lists:18 cr iter->bb_group" sudo perf probe -a "ext4_mb_good_group:20 free fragments ac->ac_g_ex.fe_len ac->ac_2order" ** Recording using the probe point ** sudo perf record -e probe:ext4_mb_find_good_group_avg_frag_lists -e probe:ext4_mb_find_good_group_avg_frag_lists_L18 -e probe:ext4_mb_good_group_L20 -e ext4:ext4_mballoc_alloc -g -p <pid> sleep 20 ** Saving the output ** sudo perf script -i perf.data > perf-probe.log I tried these commands on the mainline kernel but I hope they've not changed too much for your kernel. You *might* need to change the line numbers of the probe if thats the case and the event names in the record command would also change accordingly. Please let me know if you need any more info from my end to get this done, I'd be glad to help. Thanks again and regard, ojaswin -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
