On 15/09/2025 12:10, David Hildenbrand wrote:
> On 15.09.25 12:59, Lorenzo Stoakes wrote:
>> On Mon, Sep 15, 2025 at 12:52:53PM +0200, David Hildenbrand wrote:
>>> On 15.09.25 12:48, Lorenzo Stoakes wrote:
>>>> On Mon, Sep 15, 2025 at 12:44:34PM +0200, David Hildenbrand wrote:
>>>>>>>> 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?
>>
>> 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.
>
