Re: [PATCH mm-new v6 2/5] mm: khugepaged: refine scan progress number
From: David Hildenbrand (Arm)
Date: Thu Feb 05 2026 - 07:30:03 EST
On 2/5/26 13:07, Dev Jain wrote:
On 05/02/26 11:38 am, Vernon Yang wrote:
On Thu, Feb 5, 2026 at 5:35 AM David Hildenbrand (arm) <david@xxxxxxxxxx> wrote:
[...]I guess, your meaning is "min(_pte - pte + 1, HPAGE_PMD_NR)", not max().
*cur_progress = max(_pte - pte + 1, HPAGE_PMD_NR);
?I'm also worried that the compiler can't optimize this since the body of
It's still a bit nasty, though.
Can't we just add one at the beginning of the loop and let the compiler
optimize that? ;)
the loop is complex, as with Dev's opinion [1].
[1] https://lore.kernel.org/linux-mm/7c4b5933-7bbd-4ad7-baef-830304a09485@xxxxxxx
If you have a strong recommendation for this, please let me know, Thanks!
I haven't explicitly checked with assembly, but I am fairly sure this won't get optimized.
There are two cases where it could have been optimized:
1) Had the compiler inlined hpage_collapse_scan_pmd
Yeah, there are two callers so that likely does not happen.
2) Had the compiler done something like
if (p) -> foo(), where foo() contains the complete for loop, with the increment
else -> bar(), where bar() contains the complete for loop, without the increment
Both of which are highly unlikely because of the complexity of the function.
Not sure if the compiler would be to optimize this out also in non-inlined cases. In any case, I wonder if this must be optimized at all ...
--
Cheers,
David