On Fri, Sep 12, 2025 at 03:46:36PM +0200, David Hildenbrand wrote:

On 12.09.25 15:37, Johannes Weiner wrote:

quoted

On Fri, Sep 12, 2025 at 02:25:31PM +0200, David Hildenbrand wrote:

quoted

On 12.09.25 14:19, Kiryl Shutsemau wrote:

quoted

On Thu, Sep 11, 2025 at 09:27:55PM -0600, Nico Pache wrote:

quoted

The following series provides khugepaged with the capability to collapse
anonymous memory regions to mTHPs.

To achieve this we generalize the khugepaged functions to no longer depend
on PMD_ORDER. Then during the PMD scan, we use a bitmap to track individual
pages that are occupied (!none/zero). After the PMD scan is done, we do
binary recursion on the bitmap to find the optimal mTHP sizes for the PMD
range. The restriction on max_ptes_none is removed during the scan, to make
sure we account for the whole PMD range. When no mTHP size is enabled, the
legacy behavior of khugepaged is maintained. max_ptes_none will be scaled
by the attempted collapse order to determine how full a mTHP must be to be
eligible for the collapse to occur. If a mTHP collapse is attempted, but
contains swapped out, or shared pages, we don't perform the collapse. It is
now also possible to collapse to mTHPs without requiring the PMD THP size
to be enabled.

When enabling (m)THP sizes, if max_ptes_none >= HPAGE_PMD_NR/2 (255 on
4K page size), it will be automatically capped to HPAGE_PMD_NR/2 - 1 for
mTHP collapses to prevent collapse "creep" behavior. This prevents
constantly promoting mTHPs to the next available size, which would occur
because a collapse introduces more non-zero pages that would satisfy the
promotion condition on subsequent scans.

Hm. Maybe instead of capping at HPAGE_PMD_NR/2 - 1 we can count
all-zeros 4k as none_or_zero? It mirrors the logic of shrinker.

I am all for not adding any more ugliness on top of all the ugliness we
added in the past.

I will soon propose deprecating that parameter in favor of something
that makes a bit more sense.

In essence, we'll likely have an "eagerness" parameter that ranges from
0 to 10. 10 is essentially "always collapse" and 0 "never collapse if
not all is populated".

In between we will have more flexibility on how to set these values.

Likely 9 will be around 50% to not even motivate the user to set
something that does not make sense (creep).

One observation we've had from production experiments is that the
optimal number here isn't static. If you have plenty of memory, then
even very sparse THPs are beneficial.

Exactly.

And willy suggested something like "eagerness" similar to "swapinness" that
gives us more flexibility when implementing it, including dynamically
adjusting the values in the future.

I like the idea of abstracting it like this, and - in a rare case of kernel
developer agreement (esp. around naming :) - both Matthew, David and I rather
loved referring to this as 'eagerness' here :)

The great benefit in relation to dynamic state is that we can simply treat this
as an _abstract_ thing. I.e. 'how eager are we to establish THPs, trading off
against memory pressure and higher order folio resource consumption'.

And then we can decide how precisely that is implemented in practice - and a
sensible approach would indeed be to differentiate between scenarios where we
might be more willing to chomp up memory vs. those we are not.

This also aligns nicely with the 'grand glorious future' we all dream off (don't
we??) in THP where things are automated as much as possible and the _kernel
decides_ what's best as far as is possible.

As with swappiness, it is essentially a 'hint' to us in abstract terms rather
than simply exposing an internal kernel parameter.

(Credit to Matthew for making this abstraction suggestion in the THP cabal
meeting by the way!)

quoted

An extreme example: if all your THPs have 2/512 pages populated,
that's still cutting TLB pressure in half!

IIRC, you create more pressure on the huge entries, where you might have
less TLB entries :) But yes, there can be cases where it is beneficial, if
there is absolutely no memory pressure.

quoted

So in the absence of memory pressure, allocating and collapsing should
optimally be aggressive even on very sparse regions.

Yes, we discussed that as well in the THP cabal.

It's very similar to the max_ptes_swapped: that parameter should not exist.
If there is no memory pressure we can just swap it in. If there is memory
pressure we probably would not want to swap in much.

Yes, but at least an eagerness parameter gets us closer to this ideal.

Of course, I agree that max_ptes_none should simply never have been exposed like
this. It is emblematic of a 'just shove a parameter into a tunable/sysfs and let
the user decide' approach you see in the kernel sometimes.

This is problmeatic as users have no earthly idea how to set the parameter (most
likely never touch it), and only start fiddling should issues arise and it looks
like a viable solution of some kind.

The problem is users usually lack a great deal of context the kernel has, and
may make incorrect decisions that work in one situation but not another.

TL;DR - this kind of interface is just lazy and we have to assess these kinds of
tunables based on the actual RoI + understanding from the user's perspective.

quoted

On the flipside, if there is memory pressure, TLB benefits are very
quickly drowned out by faults and paging events. And I mean real
memory pressure. If all that's happening is that somebody is streaming
through filesystem data, the optimal behavior is still to be greedy.

Another consideration is that if we need to break large folios, we
should start with colder ones that provide less benefit, and defer the
splitting of hotter ones as long as possible.

Yes, we discussed that as well: there is no QoS right now, which is rather
suboptimal.

It's also kinda funny that the max_pte_none default is 511 right now so pretty
damn eager. Which might be part of the reason people often observe THP chomping
through resources...

quoted

Maybe a good direction would be to move splitting out of the shrinker
and tie it to the (refault-aware) anon reclaim. And then instead of a
fixed population threshold, collapse on a pressure gradient that
starts with "no pressure/thrashing and at least two base pages in THP
a region" and ends with "reclaim is splitting everything, back off".

I agree, but have to think further about how that could work in practice.

That'd be lovely actually!

--
Cheers

David / dhildenb

Cheers, Lorenzo