Re: [PATCH v2] mm: shmem: don't set large-order range for internal shmem mount

[Baolin Wang <baolin.wang@linux.alibaba.com>]

On 4/15/26 9:45 PM, Matthew Wilcox wrote:
> On Wed, Apr 15, 2026 at 04:22:53PM +0800, Baolin Wang wrote:
>> +	/*
>> +	 * Only set the large order range for tmpfs mounts. The large order
>> +	 * selection for the internal shmem mount is configured dynamically
>> +	 * via the 'shmem_enabled' interfaces, so there is no need to set a
>> +	 * large order range for the internal shmem mount's mapping.
>> +	 *
>> +	 * Note: Don't consider 'deny' for emergencies and 'force' for
>> +	 * testing.
>> +	 */
>> +	if (sbinfo->huge && !(sb->s_flags & SB_KERNMOUNT))
>>   		mapping_set_large_folios(inode->i_mapping);
> 
> This isn't how mapping_set_large_folios() is supposed to be used.
> It's supposed to indicate "does the filesystem support large folios".
> shmem should be setting it unconditionally and if there needs to be some
> other way to prevent large folios from being created, we should do that
> instead.

As discussed with David, we’ve agreed that for anonymous shmem we should 
set mapping_set_large_folios() unconditionally.

However, for tmpfs mounts, we should still respect the 'huge=' mount 
option. This was a previous performance fix, see commit 5a90c155defa 
("tmpfs: don't enable large folios if not supported").