Re: mm: tmpfs: huge=always Kconfig help understates severe space amplification

["David Hildenbrand (Arm)" <david@kernel.org>]

On 11/2/26 13:53, Dmitry Ilvokhin wrote:
> On Sat, Oct 31, 2026 at 03:19:08PM +0000, Artem S. Tashkinov wrote:
>> Hi Dmitry,
>>
>> I'd like to raise a documentation issue with the Kconfig option introduced
>> by your patch:
>>
>>     mm: shmem/tmpfs hugepage defaults config choice
>>
>> Specifically, CONFIG_TRANSPARENT_HUGEPAGE_TMPFS_HUGE_ALWAYS.
>>
>> The help text currently says:
>>
>>     Always attempt to allocate hugepage for tmpfs mount, can
>>     increase the memory footprint of applications without a
>>     guaranteed benefit but it will work automatically for all
>>     applications.
>>
>> I believe this substantially understates the potential consequences of
>> selecting this option, particularly on general-purpose systems where /tmp is
>> mounted as tmpfs.
>>
>> I recently encountered the following situation while extracting a Fedora
>> filesystem tree under /tmp on an x86-64 system running Linux 7.3.
>>
>> The tmpfs mount had huge=always enabled.
>>
>>     $ df -hT /tmp/Fedora
>>     Filesystem  Type   Size  Used  Avail  Use%
>>     tmpfs       tmpfs   48G   47G   925M   99%
>>
>>     $ du -sh /tmp/Fedora/usr
>>     45G     /tmp/Fedora/usr
>>
>>     $ du -sh --apparent-size /tmp/Fedora/usr
>>     1.4G    /tmp/Fedora/usr
>>
>> Even more strikingly:
>>
>>     $ du -sh /tmp/Fedora/usr/share/man/man3
>>     7.5G    /tmp/Fedora/usr/share/man/man3
>>
>>     $ du -sh --apparent-size /tmp/Fedora/usr/share/man/man3
>>     7.8M    /tmp/Fedora/usr/share/man/man3
>>
>> Thus, a directory containing just 7.8 MiB of apparent file data occupied
>> approximately 7.5 GiB of allocated space.
>>
>> The overall tree occupied approximately 45 GiB despite containing only 1.4
>> GiB of apparent file data.
>>
>> This is consistent with severe allocation amplification caused by
>> transparent huge pages, although I have not yet established the exact
>> breakdown of huge-page allocations and other tmpfs overhead.
> 
> Yeah, I think one can expect up to 512 amplification on x86 in the
> absolutely worst case, based on the ratio of pages sizes:
> 2 MiB to 4 KiB.
> 
> I suspect the magnitude can be even bigger on aarch64.
> 
> [...]
> 
>>
>> For example, the help might say:
>>
>>     Always attempt hugepage allocation for tmpfs mounts.
>>
>>     WARNING: This policy can substantially increase memory and
>>     tmpfs space consumption, particularly for workloads creating
>>     large numbers of small files. Allocated space may greatly
>>     exceed apparent file sizes, potentially exhausting tmpfs
>>     capacity even when relatively little file data is stored.
> 
> I would probably drop "WARNING", since there nothing to warn about yet.
> Also, second sentence communicating the same idea as the first one, but
> with different words.
> 
> Probably, something like this will be enough: "This policy can
> substantially increase memory and tmpfs space consumption, particularly
> for workloads creating large numbers of small files."
> 
>>
>>     This setting does not guarantee improved performance and
>>     should only be selected when its memory overhead is
>>     understood and acceptable for the intended workload.
> 
> This part is already mentioned in the current wording: "increase the
> memory footprint of applications without a guaranteed benefit".
> 
> Anyway, I think documentation edits are always welcome, please, submit a
> patch :)

Agreed.

BUT, one interesting detail:

On small files, the shmem unused shrinker shmem_unused_huge_shrink() should try
reclaiming such THPs that expands beyond EOF to reclaim their memory.

Artem, does that work in you scenario when there is actually memory pressure?

-- 
Cheers,

David