Re: [PATCH v4] sched/freq: move call to cpufreq_update_util

[Vincent Guittot]

On Fri, 15 Nov 2019 at 11:41, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> On Fri, Nov 15, 2019 at 11:03:20AM +0100, Rafael J. Wysocki wrote:
> > On Fri, Nov 15, 2019 at 10:55 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> > > So why are we making the scheduler code more ugly instead of fixing that
> > > driver?
> >
> > I guess we could "fix" the driver by making it rate limit MSR writes
> > only, but I'm not sure if that would help.
>
> So it is not clear to me what exactly intel_pstate needs and why. Like I
> wrote in my reply to Vincent just now, it can still store the last
> value, even if it doesn't act on it right away.
>
> And it can then act on that stored value at a later event, whatever is
> appropriate.
>
> I'm just saying that generating superfluous events is silly. But
> possibly I read the patch wrong.

This is not the intent of the patch.

Before 039ae8bcf7a5 ("sched/fair: Fix O(nr_cgroups) in the load
balancing path"), the call to cpufreq was done thanks to
update_cfs_rq_load_avg() even if cfs was already null but not irq/rt
or dl
After the patch, cpufreq was not called anymore

This patch fix this to make sure that cpufreq is called while  irq/rt
or dl is not null

Then, it also remove a spurious call to cpufreq just before attaching the task