On Thu, Sep 26, 2024 at 04:27:25PM +0800, Baolin Wang wrote: > This RFC patch series attempts to support large folios for tmpfs. The first > patch is based on Daniel's previous patches in [1], mainly using the length > in the write and fallocate paths to get a highest order hint for large > order allocation. The last patch adds mTHP filter control for tmpfs if mTHP > is set for the following reasons: > > 1. Maintain backward compatibility for the control interface. Tmpfs already > has a global 'huge=' mount option and '/sys/kernel/mm/transparent_hugepage/shmem_enabled' > interface to control large order allocations. mTHP extends this capability to a > per-size basis while maintaining good interface compatibility. ... it's confusing as hell to anyone who tries to understand it and you've made it more complicated. Well done. > 2. For the large order allocation of writable mmap() faults in tmpfs, we need > something like the mTHP interfaces to control large orders, as well as ensuring > consistent interfaces with shmem. tmpfs and shmem do NOT need to be consistent! I don't know why anyone thinks this is a goal. tmpfs should be consistent with OTHER FILE SYSTEMS. shmem should do the right thing for the shared anon use case. > 3. Ryan pointed out that large order allocations based on write length could > lead to memory fragmentation issue. Just quoting Ryan's comment [2]: > "And it's possible (likely even, in my opinion) that allocating lots of different > folio sizes will exacerbate memory fragmentation, leading to more order-0 > fallbacks, which would hurt the overall system performance in the long run, vs > restricting to a couple of folio sizes." I disagree with this. It's a buddy allocator; it's resistant to this kind of fragmentation.
