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