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

[Zhan Xusheng]

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.

> + 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?

Thanks,
Zhan Xusheng