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