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?
--
Kiryl Shutsemau / Kirill A. Shutemov
