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