Re: [PATCH v5 06/19] selftests/mm: stop khugepaged during the MADV_COLLAPSE cases

[Kiryl Shutsemau <kirill@shutemov.name>]

On Thu, Sep 10, 2026 at 02:27:28PM +0800, Baolin Wang wrote:
> 
> 
> 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)" <kas@kernel.org>
> > > > 
> > > > __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.

Please, do it as a standlone shmem fix, plus selftest update to reflect
the change.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov