Re: [PATCH v2] sparc64: increase kernel thread stack size to 32K

[Stian Halseth]

Hi Tony,

On Mon, 2026-08-31 at 13:18 -0700, Tony Rodriguez wrote:
> Hi Stian,
> 
> Just please continue to give me a 
> mention in any patches related to this work, since I spent a 
> considerable amount of time debugging, researching, and validating
> the fixes.
Sure. For now, no real changes have been made to your patches, so as
far as I'm concerned, this is entirely your work. 
Will try help with the last mile, alongside some other patches I've
submitted.
And yes, the debugging, researching and validation is the hard part. 
Writing a fix is often _relatively_ easy, when you have all the facts.
> 
> When I last tested on 7.0 and 7.1, both of my patches worked:
> 
> A)    sparc64: increase kernel thread stack size to 32K
> 
> B)    sparc64: Fix comparator problem with timer interrupts
> 
> I was able to debug and validate these issues on S7‑2 and T7‑1
> hardware. 
Yes, and that's a very important data point. My analyzis is based on
the change itself, _and_ your validation/testing. 
> I’m not sure if others have reported similar problems on T4 or T5
> systems.
Not that I'm aware of, and I haven't seen it on my T4-1.
> 
> If you have a quicker or better methodology for reviewing stack
> usage—or 
> any general suggestions—I’m definitely open to seeing them, along
> with 
> your config and exact procedure. And if you need help validating
> against 
> S7‑2 and T7‑1 hardware, I can try to allocate some time to assist.
I think that would be very helpful. Let's try to settle the 32K-vs-64K
question with more data. 

The kernel has stack measurement built in.

The in-kernel method:
  CONFIG_STACK_TRACER=y
  CONFIG_DEBUG_STACK_USAGE=y
  CONFIG_SCHED_STACK_END_CHECK=y

Boot with "stacktrace" on the kernel command line (arms the tracer
before built-in drivers probe). Then:

  cat /sys/kernel/tracing/stack_max_size   # worst case seen, bytes
  cat /sys/kernel/tracing/stack_trace      # that path, frame by frame

Reset with "echo 0 > stack_max_size" before a workload to isolate it.

For the 32K-vs-64K question, the most valuable data you could gather
is a stack_trace snapshot on the S7-2/T7-1 under your real workload
with mlx5 active, on a 32K kernel. 

On our T4-1 the worst case is 12616 bytes, but doesn't have mlx5. If
your machines stay well under 32K, we have comfortable margin. But if
something approaches the limit, the trace will name the exact frames,
and we can judge whether the right answer is 64K or a targeted fix in
that driver.
> 

Thanks!

-- 
Best regards
Stian Halseth