| Message ID | 20250211004054.222931-1-npache@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | mm: introduce THP deferred setting | expand |
On 11/02/2025 00:40, Nico Pache wrote: > This series is a follow-up to [1], which adds mTHP support to khugepaged. > mTHP khugepaged support was necessary for the global="defer" and > mTHP="inherit" case (and others) to make sense. > Hi Nico, Thanks for the patches! Why is mTHP khugepaged a prerequisite for THP=defer? THP=defer applies to PMD hugepages as well, so they should be independent.
On Mon, Feb 17, 2025 at 7:54 AM Usama Arif <usamaarif642@gmail.com> wrote: > > > > On 11/02/2025 00:40, Nico Pache wrote: > > This series is a follow-up to [1], which adds mTHP support to khugepaged. > > mTHP khugepaged support was necessary for the global="defer" and > > mTHP="inherit" case (and others) to make sense. > > > > Hi Nico, > > Thanks for the patches! Hi Usama, Thank you for the review! > > Why is mTHP khugepaged a prerequisite for THP=defer? > THP=defer applies to PMD hugepages as well, so they should be independent. Its not a hard prerequisite, but I explained it a little here: https://lore.kernel.org/lkml/CAA1CXcBPt4jHfH0Ggio5ghSYAQAXf08rO8R6b1faHzdjFf_Ajw@mail.gmail.com/ In general, the sysfs didnt really make sense without it, and given mTHPs came along right when i was working on defer, I decided to add it to mTHP too. I worked on and tested these together so it felt right to sync up the V2s for both of them. Cheers, -- Nico > > >
This series is a follow-up to [1], which adds mTHP support to khugepaged. mTHP khugepaged support was necessary for the global="defer" and mTHP="inherit" case (and others) to make sense. 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 two 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. 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 - lots of general use. These changes have been running in my VM for some time - redis testing. This test was my original case for the defer mode. What I was able to prove was that THP=always leads to increased max_latency cases; hence why it is recommended to disable THPs for redis servers. However with 'defer' we dont have the max_latency spikes and can still get the system to utilize THPs. I further tested this with the mTHP defer setting and found that redis (and probably other jmalloc users) can utilize THPs via defer (+mTHP defer) without a large latency penalty and some potential gains. I uploaded some mmtest results here [3] which compares: stock+thp=never stock+(m)thp=always khugepaged-mthp + defer (max_ptes_none=64) The results show that (m)THPs can cause some throughput regression in some cases, but also has gains in other cases. The mTHP+defer results have more gains and less losses over the (m)THP=always case. V2 Changes: - base changes on mTHP khugepaged support - Fix selftests parsing issue - add mTHP defer option - add mTHP defer Documentation [1] - https://lkml.org/lkml/2025/2/10/1982 [2] - https://gitlab.com/npache/khugepaged_mthp_test [3] - https://people.redhat.com/npache/mthp_khugepaged_defer/testoutput2/output.html Nico Pache (5): mm: defer THP insertion to khugepaged mm: document transparent_hugepage=defer usage selftests: mm: add defer to thp setting parser khugepaged: add defer option to mTHP options mm: document mTHP defer setting Documentation/admin-guide/mm/transhuge.rst | 40 ++++++++++--- include/linux/huge_mm.h | 18 +++++- mm/huge_memory.c | 69 +++++++++++++++++++--- mm/khugepaged.c | 10 ++-- tools/testing/selftests/mm/thp_settings.c | 1 + tools/testing/selftests/mm/thp_settings.h | 1 + 6 files changed, 115 insertions(+), 24 deletions(-)