Re: [PATCH v2] sched/debug, sys_info: Introduce SYS_INFO_CPU_RUNQUEUES

[Aaron Tomlin]

On Wed, Sep 23, 2026 at 10:37:53AM +0200, Peter Zijlstra wrote:
> > Yes, fair point. The intention here is to preserve this state directly
> > within the kernel log buffer, particularly for scenarios where kdump is not
> > configured, the vmcore was truncated or fails to complete.
> > In such circumstances, dmesg, whether captured via pstore or serial, is
> > frequently the sole surviving diagnostic artefact.
> 
> Ok. So not crash-dump then ;-)

Hi Peter,

Yes. Any data emitted by sys_info() that appears on the serial console will
also be captured in vmcore-dmesg.txt, even if the resulting vmcore dump to
disk is truncated due to insufficient storage.

> Right you are. Clearly I got my wires crossed when looking through that.
> 
> > With sched_show_runqueues(), it specifically avoids print_cpu() and only
> > calls print_rq(NULL, rq, cpu, false, true). Inside print_rq(), it merely
> > iterates threads under rcu_read_lock() and calls print_task(), neither of
> > which acquires rq->lock. Hence, rq->lock is never taken again, and the
> > non-blocking guarantee of the trylock remains intact throughout the entire
> > dump.
> 
> OK. So perhaps add a few comments / annotations that these paths should
> stay clear of rq-lock. It is too easy for it to get added.

Understood, will do.

> > > > +	if (si_mask & SYS_INFO_CPU_RUNQUEUES)
> > > > +		sched_show_runqueues();
> > > >  }
> > > 
> > > I really don't know if this is worth the trouble. I have *never* needed
> > > this.
> > 
> > I understand. However, the requirement primarily arises in production
> > support. In environments where kdump is not configured or the resulting
> > vmcore is truncated, dmesg is frequently the sole surviving diagnostic
> > artefact.
> > 
> > During an NMI-induced panic, capturing per-CPU runqueue depth in the log is
> > invaluable for identifying CPU starvation, etc. As with the remainder of
> > sys_info, this functionality is strictly opt-in and disabled by default,
> > imposing no overhead on systems that do not require it while providing
> > vital visibility where full memory dumps are unavailable.
> 
> What is the main thing holding 'you' back from enabling kdump
> everywhere? AFAIU crash dump can be configured to only dump kernel data
> structures, which is a lot more economical than a complete memory dump.
> 
> Mostly I just worry about death by a thousand cuts and all that. I don't
> have a very strong objection to this, just wondering if we really need
> it.

Indeed, filtering via makedumpfile (e.g. -d 31) certainly mitigates dump
file size. However, even with kdump configured, our primary motivation is
added flexibility, ensuring visibility when a usable vmcore cannot be
saved.

Unfortunately, we have encountered a dump target that run out of storage,
when prior unpurged vmcores have accumulated. When this occurs, writing
/proc/vmcore fails or gets truncated, rendering the dump too incomplete to
extract dmesg.

Crucially, kdump extract vmcore-dmesg.txt first. Because it requires only a
few megabytes, it routinely succeeds. Capturing SYS_INFO_CPU_RUNQUEUES
ensures that runnable task demand and per-CPU runqueue depth remain
preserved in vmcore-dmesg.txt (or e.g. serial console) as the sole
surviving diagnostic artefact.

Kind regards,
-- 
Aaron Tomlin