Sorry for late reply.
On 2025/5/17 14:47, Nico Pache wrote:
On Thu, May 15, 2025 at 9:20 PM Baolin Wang
<baolin.w...@linux.alibaba.com> wrote:
On 2025/5/15 11:22, Nico Pache wrote:
khugepaged scans anons PMD ranges for potential collapse to a hugepage.
To add mTHP support we use this scan to instead record chunks of utilized
sections of the PMD.
khugepaged_scan_bitmap uses a stack struct to recursively scan a bitmap
that represents chunks of utilized regions. We can then determine what
mTHP size fits best and in the following patch, we set this bitmap while
scanning the anon PMD. A minimum collapse order of 2 is used as this is
the lowest order supported by anon memory.
max_ptes_none is used as a scale to determine how "full" an order must
be before being considered for collapse.
When attempting to collapse an order that has its order set to "always"
lets always collapse to that order in a greedy manner without
considering the number of bits set.
Signed-off-by: Nico Pache <npa...@redhat.com>
Sigh. You still haven't addressed or explained the issues I previously
raised [1], so I don't know how to review this patch again...
Can you still reproduce this issue?
Yes, I can still reproduce this issue with today's (5/20) mm-new branch.
I've disabled PMD-sized THP in my system:
[root]# cat /sys/kernel/mm/transparent_hugepage/enabled
always madvise [never]
[root]# cat /sys/kernel/mm/transparent_hugepage/hugepages-2048kB/enabled
always inherit madvise [never]
And I tried calling madvise() with MADV_COLLAPSE for anonymous memory,
and I can still see it collapsing to a PMD-sized THP.
I can no longer reproduce this issue, that's why I posted... although
I should have followed up, and looked into what the original issue
was. Nothing really sticks out so perhaps something in mm-new was
broken and pulled out... not sure.
It should now follow the expected behavior, which is that no mTHP
collapse occurs because if the PMD size is disabled so is khugepaged
collapse.
Lmk if you are still experiencing this issue please.
Cheers,
-- Nico
[1]
https://lore.kernel.org/all/83a66442-b7c7-42e7-af4e-fd211d8ed...@linux.alibaba.com/
