Message ID | 20250417001846.81480-1-npache@redhat.com (mailing list archive) |
---|---|
Headers | show |
Series | mm: introduce THP deferred setting | expand |
On Wed, 16 Apr 2025 18:18:42 -0600 Nico Pache <npache@redhat.com> wrote: > This series is a follow-up to [1], which adds mTHP support to khugepaged. > mTHP khugepaged support is a "loose" dependency for the sysfs/sysctl > configs to make sense. Without it global="defer" and mTHP="inherit" case > is "undefined" behavior. > > We've seen cases were customers switching from RHEL7 to RHEL8 see a > significant increase in the memory footprint for the same workloads. > > Through our investigations we found that a large contributing factor to > the increase in RSS was an increase in THP usage. > > For workloads like MySQL, or when using allocators like jemalloc, it is > often recommended to set /transparent_hugepages/enabled=never. This is > in part due to performance degradations and increased memory waste. > > This series introduces enabled=defer, this setting acts as a middle > ground between always and madvise. If the mapping is MADV_HUGEPAGE, the > page fault handler will act normally, making a hugepage if possible. If > the allocation is not MADV_HUGEPAGE, then the page fault handler will > default to the base size allocation. The caveat is that khugepaged can > still operate on pages thats not MADV_HUGEPAGE. > > This allows for three things... one, applications specifically designed to > use hugepages will get them, and two, applications that don't use > hugepages can still benefit from them without aggressively inserting > THPs at every possible chance. This curbs the memory waste, and defers > the use of hugepages to khugepaged. Khugepaged can then scan the memory > for eligible collapsing. Lastly there is the added benefit for those who > want THPs but experience higher latency PFs. Now you can get base page > performance at the PF handler and Hugepage performance for those mappings > after they collapse. > > Admins may want to lower max_ptes_none, if not, khugepaged may > aggressively collapse single allocations into hugepages. > > TESTING: > - Built for x86_64, aarch64, ppc64le, and s390x > - selftests mm > - In [1] I provided a script [2] that has multiple access patterns Namely https://gitlab.com/npache/khugepaged_mthp_test? Looks useful and could perhaps be directly linked to from this patchset's [0/N] changelog?