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.gm2...@hirez.programming.kicks-ass.net > > > > (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.
