Re: [PATCH v4 04/19] selftests/mm: skip khugepaged page cache cases without a PMD folio

On Tue, Aug 18, 2026 at 11:07:55AM +0100, Lorenzo Stoakes (ARM) wrote:
> > diff --git a/tools/testing/selftests/mm/khugepaged.c b/tools/testing/selftests/mm/khugepaged.c
> > index c499804a0ec4..ec5c36a19d92 100644
> > --- a/tools/testing/selftests/mm/khugepaged.c
> > +++ b/tools/testing/selftests/mm/khugepaged.c
> > @@ -1357,6 +1357,30 @@ int main(int argc, char **argv)
> >
> >  	setbuf(stdout, NULL);
> >
> > +	/*
> > +	 * The page cache caps folio order at MAX_PAGECACHE_ORDER, which is
> > +	 * below the PMD order on arm64 with 64K pages.  A PMD-sized page cache
> > +	 * folio is impossible there, so the kernel refuses these collapses by
> > +	 * design and there is nothing to test.  The cap is not shmem-specific:
> > +	 * it rules out regular files too, and the per-order shmem_enabled
> > +	 * controls exist for exactly the orders it allows, which is what makes
> > +	 * them readable here.
> > +	 */
> 
> This is a very schloppy comment. Can you trim it please?

Will do.

> > +	if (!(thp_shmem_supported_orders() & (1UL << hpage_pmd_order))) {
> 
> Is this inferring file-backed khugepaged behaviour from shmem? That seems iffy.

The helper is named after shmem but the sysfs set is the page cache one.
`thpsize_create()` creates the per-order `shmem_enabled` attribute under one
condition:

	if (BIT(order) & THP_ORDERS_ALL_FILE_DEFAULT) {

and that mask is orders 1 to `MAX_PAGECACHE_ORDER`.

So hugepages-<N>kB/shmem_enabled exists means "the page cache can hold an
order-N folio", for regular files as much as for shmem.

thp_shmem_supported_orders() name is confusing. I think, I will add
`thp_file_supported_orders()` over the same sysfs walk and use that
here.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov