On 9/9/26 6:41 PM, Kiryl Shutsemau wrote:
On Wed, Sep 09, 2026 at 05:55:01PM +0800, Baolin Wang wrote:
On 9/8/26 8:50 PM, Kiryl Shutsemau wrote:
From: "Kiryl Shutsemau (Meta)" <[email protected]>
__madvise_collapse() turns THP off before each MADV_COLLAPSE, both to keep
khugepaged out of the range and to prove MADV_COLLAPSE ignores the setting.
It clears the global controls only, which is no longer enough. A per-order
control overrides them, and -s, which makes the cases fault in folios of
one order, leaves that order's control at "always". khugepaged then
collapses the very range the case is working on, and the case fails on a
collapse that was interfered with rather than refused.
Right. So I think the correct fix tag is b7f16963efe7 ("mm/khugepaged: run
khugepaged for all orders"), because before this commit, khugepaged would
not try to collapse this range since it only checked whether the PMD order
was suitable for collapse.
Agreed. The series is in mm-new already; if a respin is needed I will use
that tag.
@@ -547,9 +547,16 @@ static void __madvise_collapse(const char *msg, char *p,
int nr_hpages,
/*
* Prevent khugepaged interference and tests that MADV_COLLAPSE
* ignores /sys/kernel/mm/transparent_hugepage/enabled
+ *
+ * "inherit" rather than "never" so that MADV_COLLAPSE on shmem still
+ * finds an order to build.
*/
settings.thp_enabled = THP_NEVER;
settings.shmem_enabled = SHMEM_NEVER;
+ for (i = 0; i < NR_ORDERS; i++) {
+ settings.hugepages[i].enabled = THP_INHERIT;
+ settings.shmem_hugepages[i].enabled = SHMEM_INHERIT;
+ }
This looks like a workaround to me. Shouldn't we fix this in shmem instead?
Good point.
It can be a follow-up patch. Do you want to make a proper shmem.c fix
and update the selftest along with it?
Either way works for me.
