Re: [PATCH] nptl: Disable THP on thread stack if it incurs in large RSS usage

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 17/05/23 09:49, Wilco Dijkstra wrote:
> Hi Adhemerval,
> 
>>> The question is, under what circumstances are huge pages in stacks beneficial and
>>> in which cases are they not? If have a good answer to that, then we can automatically
>>> do the right thing without needing a tuning.
>>>
>>
>> Afaiu the issue is not whether huge page in stacks is beneficial, but rather 
>> when kernel will fall back to default pages anyway which will be just waste 
>> cycles.  Another option would be tune the default stack and guard size
>> to avoid this issue, but this might require some more heuristics to find a 
>> good spot to avoid too much VMA waste.
> 
> The kernel won't fallback to standard pages - like I said, it really allocates a huge
> page when it can (based on alignment of the stack) and that is what causes the
> increase of RSS size. But that's not evidence of an issue.

AFAIU the issue is after the stack is allocated with huge pages, the
kernel needs to fallback to standard pages because the guard 'page'
will be also within the same huge page allocated for the stack.  

My understanding is, once kernel needs to fallback to use default pages, 
it allocates *all* the large page range.  This is what the RSS increase
make me believe, I am not sure if there is technical limitation to just 
making the range COW (since at the time of guard protection setup, no
the page has not been touched yet).

> 
> So the real question is when do huge pages make sense for stacks?

But that's not what the patch is trying to do, it only tries tot mitigate
a specific corner case where THP will be ineffective.  I agree with
Cupertino that this question is really hard to answer and it will be
really depended of the workload and/or runtime characteristics that we will
need to plug in kernel feedback to have some answer.