Re: [PATCH v2 00/13] Dynamic Kernel Stacks

[Thomas Gleixner]

On Mon, Jun 22 2026 at 16:00, Zach O'Keefe wrote:
> On Sat, Jun 20, 2026 at 4:34 PM Thomas Gleixner <tglx@xxxxxxxxxx> wrote:
>> That said you really have to describe the scenarios where there is a
>> benefit and I do not buy this "fleet level" argument at all because
>> there is no single fleet which has a uniform workload distribution.
>
> These are good thoughts, thank you. Perhaps I've been too biased by
> our particular environment—apologies for that.
>
> We (mostly) punt this problem to cluster-level scheduling, which
> ironically exploits this non-uniformity of workload dynamics to
> appropriately bin-pack machines and materialize these small savings.

That makes sense.

> In the general case, I guess a lot hinges on that overhead cost -- in
> the best (memory-constrained) case.

Right, we need to look at the wide range of use cases and avoid to
create niche solutions which impose maintenance costs for everyone.

>> Aside of that. If your argument holds that there are only a few
>> scenarios which require a deep stack, then we are better off to identify
>> them and fix them up rather than trying to hack around the occacional
>> insanity of deep stack usage by adding complexity for complexity sake.
>>
>> As you say that you have numbers of your fleet which confirm that the
>> vast majority of the stack depth is below 4k, you can surely figure out
>> the information which call chains are actually exceeding the limit.
>>
>> I prefer to fix such shitty code and downgrade the stacksize in general
>> instead of papering over the underlying issues which probably have been
>> ignored for years if not decades.
>>
>> Have you ever thought about that instead of adding complexity with a
>> dubious value?
>
> Yeah, and that is certainly an alternative path we can explore. I was
> _hoping_ to be able to maximize the savings here, via the >90% case
> where 4KiB is sufficient. If we instead play whack-a-mole with the
> handful of cases requiring > 8KiB, the best case is we can move back
> to 8KiB stacks. Ironically, I was thinking going this route would be
> _more_ of a maintenance burden vs having a generalized solution ;)

It's actually not. The point is that we lazily punted to 16K stacks more
than 10 years ago. If you read the changelog carefully there is an
implicit request to watch out for stack usage and to fix the
offenders. That's obviously not worth the electrons it wasted to commit
it.

Software people are really good in not ignoring such things as long as
they do not explode in their face. :)

So as you already confirmed that the number of offenders is really low,
it'd be definitely a worthwhile effort to fix that for everyone and also
make the compiler people to get their act together :)

Once we got there the complexity of this becomes smaller and we might
have a common goal to get the other 90% solved.

Thanks,

        tglx