The transparent huge page shrinker [LWN.net]

The transparent huge page shrinker

Posted Sep 11, 2022 14:30 UTC (Sun) by tamara_schmitz (guest, #141258)
Parent article: The transparent huge page shrinker

SUSE has set thp enable to always and defrag to madvise.
I wonder what's the history there.

to post comments

The transparent huge page shrinker

Posted Sep 12, 2022 12:51 UTC (Mon) by jtaylor (guest, #91739) [Link] (1 responses)

From my memory the main issues encountered with thp were mostly poor scalability of the defragmentation on large machines.

When we first saw it was I think a RHEL 6 where thp were immediately backported to some very old kernel version and enabled with defrag by default.
On machines with many cpu cores and certain workloads this caused basically 100% system load defragmenting.

The fix back then for us was disabling the automatic defragmentation and only run it when needed. Though many opted to just flat out disabling it globally and since then thp has a pretty bad reputation despite the issues mostly all being fixed today.

The transparent huge page shrinker

Posted Sep 13, 2022 16:17 UTC (Tue) by WolfWings (subscriber, #56790) [Link]

The other long-standing issue has been software using jemalloc which doesn't actually 'free' memory when it's done with it most of the time but just uses MADV_DONTNEED and MADV_FREE so it ends up actively fighting with khugepaged which then re-faults those 'all zero' pages to merge them together again since they're still tied to the process.

So in effect software using jemalloc with THP enabled and lots of small allocations and frees would suddenly have the worst-case "lots of wasted RAM" situation almost immediately.

It's also why so much jemalloc-using software has a much higher resident size quite often is from all of those "I'm done with these... but I won't pay the memory-fault costs to actually free them (BENCHMARKS, AHOY!) so I'll use the lazy-free madvise call instead" situations.