On 15/09/2025 12:10, 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.

Do you mean stop people from changing max_ptes_none? I am not sure if thats a good idea,
Its existed for a very long time and even a few release warnings might not be enough
of a warning for sysadmins that might not have a kernel team to notice this.

If the eagerness solution is just a logarithmic mapping of max_ptes_none at the start, I do
think we need to keep max_ptes_none completely supported. As eagerness isnt really doing
something new? Once eagnerness diverges from just setting max_ptes_none, only then
we should start thinking about deprecating it?

quoted

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.

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.