Re: [PATCH v2 12/13] x86: Add support for dynamic kernel stacks via FRED

[Thomas Gleixner]

On Mon, Jun 29 2026 at 07:52, H. Peter Anvin wrote:
> On June 29, 2026 1:41:13 AM PDT, Thomas Gleixner <tglx@xxxxxxxxxx> wrote:
>>On Sun, Jun 28 2026 at 13:33, H. Peter Anvin wrote:
>>>
>>> To be fair, for this *specific* case, memmove() does exist for a reason :)
>>
>> It does, but why bother doing actual work, if you know upfront that it's
>> not required :)
>
> Of course. 
>
> Then there is the very open question if this thing has legs at
> all.

The jury is still out on that :)

> I'm still interested in using SL1 for the interrupt stack as I think
> that could be a performance boost.

I'm not convinced that it will give you a measurable boost.

It spares the trivial stack switch to/from the interrupt stack in
call_on_stack() and the hardirq_stack_inuse logic around it. With an
interrupt rate of 50KHz and 10 instructions spared, that gives you
0.025% performance win on a 2GHz machine.

But if need_resched() is set the return path has to do the full stack
pivot to the SL0 stack. That's a memcpy() of sizeof(fred_frame) + the
extra stack consumption including common_interrupt(), which accumulates
to ~256 bytes, i.e. four cache lines. Plus the FRED_CONFIG MSR write.

IOW, if need_resched() is set, it's a guaranteed loss and latency
sensitive scenarios including RT will notice.

Thanks,

        tglx