On Wed, Mar 17, 2021 at 05:06:31PM -0700, Josh Don wrote: > On Wed, Mar 17, 2021 at 1:25 AM Ingo Molnar <mingo@xxxxxxxxxx> wrote: > > > > * Josh Don <joshdon@xxxxxxxxxx> wrote: > > > > > If resched_latency_warn_ms is set to the default value, only one warning > > > will be produced per boot. > > > > Looks like a value hack, should probably be a separate flag, > > defaulting to warn-once. > > Agreed, done. > > > > This warning only exists under CONFIG_SCHED_DEBUG. If it goes off, it is > > > likely that there is a missing cond_resched() somewhere. > > > > CONFIG_SCHED_DEBUG is default-y, so most distros have it enabled. > > To avoid log spam for people who don't care, I was considering having > the feature default disabled. Perhaps a better alternative is to only > show a single line warning and not print the full backtrace by > default. Does the latter sound good to you? > Default disabling and hidden behind a static branch would be useful because the majority of users are not going to know what to do about a need_resched warning and the sysctl is not documented. As Ingo said, SCHED_DEBUG is enabled by default a lot. While I'm not sure what motivates most distributions, I have found it useful to display topology information on boot and in rare cases, for the enabling/disabling of sched features. Hence, sched debug features should avoid adding too much overhead where possible. The static branch would mean splitting the very large inline functions adding by the patch. The inline section should do a static check only and do the main work in a function in kernel/sched/debug.c so it has minimal overhead if unused. -- Mel Gorman SUSE Labs
