Messages in this thread | | | Date | Fri, 25 Jun 2021 12:04:32 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH] sched/debug: Don't update sched_domain debug directories before sched_debug_init() |
| |
On Tue, May 18, 2021 at 02:07:25PM +0100, Valentin Schneider wrote: > Since CPU capacity asymmetry can stem purely from maximum frequency > differences (e.g. Pixel 1), a rebuild of the scheduler topology can be > issued upon loading cpufreq, see: > > arch_topology.c::init_cpu_capacity_callback() > > Turns out that if this rebuild happens *before* sched_debug_init() is > run (which is a late initcall), we end up messing up the sched_domain debug > directory: passing a NULL parent to debugfs_create_dir() ends up creating > the directory at the debugfs root, which in this case creates > /sys/kernel/debug/domains (instead of /sys/kernel/debug/sched/domains). > > This currently doesn't happen on asymmetric systems which use cpufreq-scpi > or cpufreq-dt drivers, as those are loaded via > deferred_probe_initcall() (it is also a late initcall, but appears to be > ordered *after* sched_debug_init()). > > Ionela has been working on detecting maximum frequency asymmetry via ACPI, > and that actually happens via a *device* initcall, thus before > sched_debug_init(), and causes the aforementionned debugfs mayhem. > > One option would be to punt sched_debug_init() down to > fs_initcall_sync(). Preventing update_sched_domain_debugfs() from running > before sched_debug_init() appears to be the safer option. > > Link: http://lore.kernel.org/r/20210514095339.12979-1-ionela.voinescu@arm.com > Fixes: 3b87f136f8fc ("sched,debug: Convert sysctl sched_domains to debugfs") > Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
Thanks!
| |