https://bugzilla.kernel.org/show_bug.cgi?id=217965 --- Comment #61 from Ojaswin Mujoo (ojaswin.mujoo@xxxxxxx) --- Hi Matthew, thanks for confirming. So as pointed out in comment 9 [1], for the above steps to disable CR_BEST_AVAIL_LEN code did not fix the issue. My suspicion is that this issue can occur either in CR_GOAL_LEN_FAST or CR_BEST_AVAIL_LEN lookup, depending on the block groups being searched. Probably for you, it was occurring during CR_BEST_AVAIL_LEN lookup and hence disabling that code fixed it. Further, as Carlos pointed out above, they are able to see this in all 6.* kernels which means this is happening before CR_BEST_AVAIL_LEN was introduced however it seems to be much easier to trigger in 6.5+ kernels. Now, assuming the above theory is correct, then in cases where this is triggered from CR_GOAL_LEN_FAST, it should ideally happen easily in pre 6.5 kernels as well, but it doesn't, which makes me think that there might be some other related changes in 6.5 that might be making it easier to trigger. I'll try to play around a bit more with this. Also, as for higher CPU usage, how high are we talking about? So CR_BEST_AVAIL_LEN does add some extra cycles at the cost of generally faster allocation in fragmented filesystems, however since you have disabled it we shouldn't ideally be seeing it. Also, does the CPU util consistently drop when you commented out that code? [1] https://bugzilla.kernel.org/show_bug.cgi?id=217965#c9 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
