Re: [PATCH] sched/debug: Introduce per-CPU debugfs files

[Aaron Tomlin]

On Tue, Jul 28, 2026 at 02:34:36PM +0800, Zhan Xusheng wrote:
> From: Zhan Xusheng <zhanxusheng1024@xxxxxxxxx>
> 
> On Mon, Jul 27, 2026 at 10:03:09PM -0400, Aaron Tomlin wrote:
> > Currently, accessing scheduler debugging details for a specific CPU
> > requires reading /sys/kernel/debug/sched/debug, which outputs
> > information for all online CPUs. This results in redundant output and
> > parsing overhead on large SMP systems when targeting an individual CPU.
> 
> This looks like a handy addition. One thing that might strengthen the
> changelog: the bigger win of a targeted per-CPU file isn't really the
> userspace parsing overhead (a grep over the existing file is cheap), but
> that inspecting a single CPU no longer requires walking every runqueue and
> taking each rq lock to produce the full dump - which is what actually
> perturbs a large, busy system. Framing it that way makes the case more
> compelling.

Hi Zhan,

Thank you for taking the time to review this patch and for the constructive feedback.

I agree. Reframing the rationale around usability and system perturbation,
provides a much stronger justification. I shall refine the commit log in v2
to emphasise this benefit.

> 
> > + for_each_possible_cpu(cpu) {
> > +   struct dentry *d_cpu;
> > +
> > +   snprintf(buf, sizeof(buf), "cpu%lu", cpu);
> > +   d_cpu = debugfs_create_dir(buf, d_cpu_dir);
> > +
> > +   debugfs_create_file("debug", 0444, d_cpu, (void *) cpu, &sched_debug_cpu_fops);
> > + }
> 
> One design question: the existing /sys/kernel/debug/sched/debug only
> iterates cpu_online_mask, whereas this creates cpu<N>/debug
> for_each_possible_cpu. Reading an offline (or never-onlined) CPU's file
> then calls print_cpu() on a quiescent rq. As far as I can tell that is
> harmless - rq->curr is that CPU's idle task from boot, so it just prints
> idle/zeroed values - but it does differ from the existing interface, and
> where possible CPUs greatly exceed online ones it adds many directories
> for CPUs that will never report anything interesting. Was exposing all
> possible CPUs intentional, or would gating the files (or their contents)
> on online CPUs be preferable?

Creating entries for for_each_possible_cpu() was intentional to keep the
debugfs directory structure static, thereby avoiding the complexity of
registering CPU hotplug notifiers to dynamically create and destroy
dentries during CPU online and offline events (i.e., matching fair_server
and ext_server initialisation).

However, to better align with /sys/kernel/debug/sched/debug and avoid
printing uninteresting data for offline CPUs, we could gate the read output
in sched_debug_cpu_show():

        if (!cpu_online(cpu))
            return -ENODEV;


Kind regards,
-- 
Aaron Tomlin