On 08.11.24 05:12, Baolin Wang wrote:
Traditionally, tmpfs only supported PMD-sized huge folios. However nowadays with other file systems supporting any sized large folios, and extending anonymous to support mTHP, we should not restrict tmpfs to allocating only PMD-sized huge folios, making it more special. Instead, we should allow tmpfs can allocate any sized large folios. Considering that tmpfs already has the 'huge=' option to control the huge folios allocation, we can extend the 'huge=' option to allow any sized huge folios. The semantics of the 'huge=' mount option are: huge=never: no any sized huge folios huge=always: any sized huge folios huge=within_size: like 'always' but respect the i_size huge=advise: like 'always' if requested with fadvise()/madvise() Note: for tmpfs mmap() faults, due to the lack of a write size hint, still allocate the PMD-sized huge folios if huge=always/within_size/advise is set.
So, no fallback to smaller sizes for now in case we fail to allocate a PMD one? Of course, this can be added later fairly easily.
Moreover, the 'deny' and 'force' testing options controlled by '/sys/kernel/mm/transparent_hugepage/shmem_enabled', still retain the same semantics. The 'deny' can disable any sized large folios for tmpfs, while the 'force' can enable PMD sized large folios for tmpfs. Any comments and suggestions are appreciated. Thanks. Hi David, I did not add a new Kconfig option to control the default behavior of 'huge=' in the current version. I have not changed the default behavior at this time, and let's see if there is a need for this.
Likely we want to change the default at some point so people might get a benefit in more scenarios automatically. But I did not investigate how /tmp is mapped as default by Fedora, for example.
-- Cheers, David / dhildenb
