On Mon, Apr 13, 2026 at 03:20:19PM -0400, Zi Yan wrote:
> collapse_file() requires FSes supporting large folio with at least
> PMD_ORDER, so replace the READ_ONLY_THP_FOR_FS check with that.
> MADV_COLLAPSE ignores shmem huge config, so exclude the check for shmem.
>
> While at it, replace VM_BUG_ON with VM_WARN_ON_ONCE.
Why? These are bugs. I don't think we gain anything from continuing.
> + /*
> + * skip files without PMD-order folio support
> + * do not check shmem, since MADV_COLLAPSE ignores shmem huge config
> + */
> + if (!shmem_file(file) && mapping_max_folio_order(mapping) < PMD_ORDER)
> + return SCAN_FAIL;
I wonder if it should. If the commit message to 5a90c155defa is
to be believed,
Since 'deny' is for emergencies and 'force' is for testing, performance
issues should not be a problem in real production environments, so don't
call mapping_set_large_folios() in __shmem_get_inode() when large folio is
disabled with mount huge=never option (default policy).
so maybe MADV_COLLAPSE should honour huge=never?
Documentation/filesystems/tmpfs.rst implies that we do!
huge=never Do not allocate huge pages. This is the default.
huge=always Attempt to allocate huge page every time a new page is needed.
huge=within_size Only allocate huge page if it will be fully within i_size.
Also respect madvise(2) hints.
huge=advise Only allocate huge page if requested with madvise(2).
so what's the difference between huge=never and huge=madvise?
