On 27-07-17, 12:55, Saravana Kannan wrote: > Yes. Simplifying isn't always about number of lines of code. It's also about > abstraction. Having generic scheduler code care about HW details doesn't > seem nice.
I can argue that even the policy->cpus field is also hardware specific, isn't it ? And we are using that in the schedutil governor anyway. What's wrong with having another field (in a generic way) in the same structure that tells us more about hardware ? And then schedutil isn't really scheduler, but a cpufreq governor. Just like ondemand/conservative, which are also called from the same scheduler path. > It'll literally one simple check (cpu == smp_processor_id()) or (cpu "in" > policy->cpus). > > Also, this is only for drivers that currently support fast switching. How > many of those do you have? Why? Why shouldn't we do that for the other drivers? I think it should be done across everyone. > >The core already has most of the data required and I believe that we > >need to handle it in the governor's code as is handled in this series. > > Clearly, it doesn't. You are just making assumptions about HW. So assuming that any CPU from a policy can change freq on behalf of all the CPUs of the same policy is wrong? That is the basis of how the cpufreq core is designed. -- viresh
