On 13 Apr 2026, at 16:20, Matthew Wilcox wrote: > 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.
The goal is to catch these issues during development. VM_BUG_ON crashes the system and that is too much for such issues in collapse_file(). > >> + /* >> + * 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? I think madvise means MADV_HUGEPAGE for the region, not MADV_COLLAPSE. In v1, I did the check for shmem, but that regressed MADV_COLLAPSE, which always can collapse THPs on shmem. I know it sounds unreasonable, but that ship has sailed. Best Regards, Yan, Zi
