Re: [PATCH 2/2] thermal: cpufreq_cooling: Reuse effective_cpu_util()

[Peter Zijlstra]

On Thu, Oct 22, 2020 at 04:36:56PM +0530, Viresh Kumar wrote:
> On 22-10-20, 11:05, Peter Zijlstra wrote:
> > On Thu, Oct 22, 2020 at 02:02:55PM +0530, Viresh Kumar wrote:
> > > One of the issues I see with this is that schedutil may not be
> > > available in all configurations and it is still absolutely fine to
> > > using the suggested helper to get the energy numbers in such cases, so
> > > we shouldn't really make it scheutil dependent.
> > 
> > The only constraint on schedutil is SMP I think; aside from that it
> > should/could always be available.
> > 
> > Given the trainwreck here:
> > 
> >   20201022071145.GM2628@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > 
> > (you're on Cc), I'm starting to lean more and more towards making it
> > unconditionally available (when SMP).
> > 
> > Anybody forcing it off either sets performance (in which case we don't
> > care about energy usage anyway)
> 
> I agree.
> 
> > or they select one of the old (broken)
> > ondemand/conservative things and I don't give a crap.
> 
> The other kernel layers, for example cpufreq-cooling in question here,
> don't really need to bother with the governor in use and should be
> able to get the energy numbers anyway. So for me, the energy number
> that the cpufreq-cooling stuff gets should be same irrespective of the
> governor in use, schedutil or ondemand.
> 
> Having said that, schedutil really doesn't need to install the
> fallback (which you suggested earlier), rather the scheduler core can
> do that directly with cpufreq core and schedutil can also use the same
> fallback mechanism maybe ? And so we can avoid the exporting of stuff
> that way.

I suppose that could work, yes. It's a bit weird to have two
interactions with cpufreq, once through a governor and once outside it,
but I suppose I can live with that.