Messages in this thread | | | Date | Fri, 15 Nov 2019 14:46:03 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH v4] sched/freq: move call to cpufreq_update_util |
| |
On Fri, Nov 15, 2019 at 02:30:58PM +0100, Vincent Guittot wrote: > On Fri, 15 Nov 2019 at 14:02, Peter Zijlstra <peterz@infradead.org> wrote: > > > > On Fri, Nov 15, 2019 at 12:03:31PM +0100, Vincent Guittot wrote: > > > > > This patch does 2 things: > > > - fix the spurious call to cpufreq just before attaching a task > > > > Right, so that one doesn't concern me too much. > > > > > - make sure cpufreq is still called when cfs is 0 but not irq/rt or dl > > > > But per the rq->has_blocked_load logic we would mostly stop sending > > events once we reach all 0s. > > > > Now, most of those updates will be through _nohz_idle_balance() -> > > update_nohz_stats(), which are remote, which means intel_pstate is > > ignoring them anyway. > > > > Now the _nohz_idle_balance() -> update_blocked_averages() thing runs > > local, and that will update the one random idle CPU we picked to run > > nohz balance, but all others will be left where they were. > > > > So why does intel_pstate care... Esp. on SKL+ with per-core P state this > > is of dubious value. > > Doug mentioned some periodic timers that were running on the CPUs > > > > > Also, and maybe I should go read back, why do we care what the P state > > is when we're mostly in C states anyway? These are all idle CPUs, > > otherwise we wouldkn't be running update_blocked_averages() on them > > anyway. > > AFAIU, there is not 100% idle but they have periodic timers that will > fire and run at higher P state
If it is pure timers, I don't see how those CPUs end up calling cpufreq_update_util().
Per the above argument, only the CPU that ran nohz balance gets an update call, all the other CPUs that remain idle (or only serve IRQs) never get the call.
| |