On Mon, Sep 15, 2025 at 01:10:22PM +0200, David Hildenbrand wrote:

On 15.09.25 12:59, Lorenzo Stoakes wrote:

quoted

On Mon, Sep 15, 2025 at 12:52:53PM +0200, David Hildenbrand wrote:

quoted

On 15.09.25 12:48, Lorenzo Stoakes wrote:

quoted

On Mon, Sep 15, 2025 at 12:44:34PM +0200, David Hildenbrand wrote:

quoted

quoted

quoted

quoted

Mapping that to actual THP sizes (#pages in a thp) on an arch will be easy.

And at different mTHP levels too right?

Another point here, since we have to keep:

/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none

Around, and users will try to set values there, presumably we will now add:

/sys/kernel/mm/transparent_hugepage/khugepaged/eagerness

How will we map <-> the two tunables?

Well, the easy case if someone updates eagerness, then we simply et it to
whatever magic value we compute and document.

The other direction is more problematic, likely we'll simply warn and do
something reasonable (map it to whatever eagerness scale is closest or
simply indicate it as "-1" -- user intervened or sth like that)

I don't love the idea of a -1 situation, as that's going to create some
confusion.

swapiness also has a "max" parameter, so we could just say "override" /"
disabled" / whatever?

I don't love the user being able to override this though, let's just nuke their
ability to set this pleeeease.

Because if they can override it, then we have to do some deeply nasty scaling
for mTHP again.

There are ways to have it working internally, just using a different "scale"
instead of the 100 -> 50 -> 25 etc.

Right. I mean with the exponential scale we could just algorithimically figure
out what the eagerness should be.

I am afraid we cannot change the parameter to ignore other values because of
the interaction with the shrinker that easily .... we might be able to
detracted at wait a bunch of kernel releases probably.

:(

BTW 'Detracted at wait'? :P You mean we might be able to remove after a few
releases?

--
Cheers

David / dhildenb

Cheers, Lorenzo