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

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

[Artem S. Tashkinov]

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.

The problem with the existing Kconfig help is not that it fails to 
mention additional memory consumption. It does mention that.

The problem is that "can increase the memory footprint" gives no 
indication of the magnitude involved, nor does it explain the workloads 
most likely to suffer.

A kernel builder selecting "always" may reasonably expect better 
performance at the cost of somewhat higher memory consumption. The help 
does not adequately warn that workloads involving many small files can 
experience extreme space amplification, potentially exhausting a tmpfs 
filesystem containing relatively little actual data.

There is also an important distinction between enabling transparent huge 
pages for selected workloads and making huge-page allocation the default 
policy for all tmpfs mounts.

I suggest expanding the Kconfig help text to explicitly mention:

- The potential for very large allocation overhead with small files.
- The risk of exhausting tmpfs space far sooner than apparent file sizes 
would suggest.
- The fact that selecting "always" is not a universal performance 
optimisation.
- The availability of "never", "within_size", and "advise" as 
alternative policies.

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.

     This setting does not guarantee improved performance and
     should only be selected when its memory overhead is
     understood and acceptable for the intended workload.

     Consider "never", "within_size", or "advise" for
     general-purpose systems.

I appreciate that the upstream default remains "never". My concern is 
specifically that the help text does not adequately communicate the 
consequences of explicitly selecting "always".

A more prominent warning would help kernel builders make an informed 
choice and avoid potentially severe memory consumption surprises.

Regards,
Artem

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

[Dmitry Ilvokhin]

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 :)

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

[David Hildenbrand (Arm)]

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