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
