On Wed, Feb 23, 2022 at 10:40 AM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > > Rafael, > > On Tue, Feb 22 2022 at 19:04, Rafael J. Wysocki wrote: > > On Tue, Feb 22, 2022 at 8:41 AM Feng Tang <feng.tang@xxxxxxxxx> wrote: > >> There is periodic activity in between, related to active load balancing > >> in scheduler (since last frequency was higher these small work will > >> also run at higher frequency). But those threads are not CFS class, so > >> scheduler callback will not be called for them. > >> > >> So removing the patch removed a trigger which would have caused a > >> sched_switch to a CFS task and call a cpufreq/intel_pstate callback. > > > > And so this behavior needs to be restored for the time being which > > means reverting the problematic commit for 5.17 if possible. > > No. This is just papering over the problem. Just because the clocksource > watchdog has the side effect of making cpufreq "work", does not make it > a prerequisite for cpufreq. The commit unearthed a problem in the > cpufreq code, so it needs to be fixed there. > > Even if we'd revert it then, you can produce the same effect by adding > 'tsc=reliable' to the kernel command line which disables the clocksource > watchdog too. The commit is there to deal with modern hardware without > requiring people to add 'tsc=reliable' to the command line. Allright (but I'll remember this exception).
