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

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

[Aaron Tomlin]

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.

Add support for per-CPU debug files under:
/sys/kernel/debug/sched/cpu/cpu<N>/debug. Reading
/sys/kernel/debug/sched/cpu/cpu<N>/debug calls print_cpu() specifically
for CPU <N>, exposing CPU-specific runqueue details on demand.

Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
---
 kernel/sched/debug.c | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index 40584b27ea0c..15785a414134 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -356,6 +356,7 @@ static const struct file_operations sched_verbose_fops = {
 };
 
 static const struct seq_operations sched_debug_sops;
+static void print_cpu(struct seq_file *m, int cpu);
 
 static int sched_debug_open(struct inode *inode, struct file *filp)
 {
@@ -633,6 +634,44 @@ static void debugfs_fair_server_init(void)
 	}
 }
 
+static int sched_debug_cpu_show(struct seq_file *m, void *v)
+{
+	unsigned long cpu = (unsigned long) m->private;
+
+	print_cpu(m, cpu);
+	return 0;
+}
+
+static int sched_debug_cpu_open(struct inode *inode, struct file *filp)
+{
+	return single_open(filp, sched_debug_cpu_show, inode->i_private);
+}
+
+static const struct file_operations sched_debug_cpu_fops = {
+	.open		= sched_debug_cpu_open,
+	.read		= seq_read,
+	.llseek		= seq_lseek,
+	.release	= single_release,
+};
+
+static __init void debugfs_cpu_init(void)
+{
+	struct dentry *d_cpu_dir;
+	unsigned long cpu;
+	char buf[16];
+
+	d_cpu_dir = debugfs_create_dir("cpu", debugfs_sched);
+
+	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);
+	}
+}
+
 static __init int sched_init_debug(void)
 {
 	struct dentry __maybe_unused *numa, *llc;
@@ -690,6 +729,7 @@ static __init int sched_init_debug(void)
 #ifdef CONFIG_SCHED_CLASS_EXT
 	debugfs_ext_server_init();
 #endif
+	debugfs_cpu_init();
 
 	return 0;
 }
-- 
2.55.0

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

[Zhan Xusheng]

From: Zhan Xusheng <zhanxusheng1024@gmail.com>

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