On 10/12/2015 08:23 PM, Viresh Kumar wrote:
On 12-10-15, 12:12, Saravana Kannan wrote:
if (new_policy) { /* related_cpus should at least include policy->cpus. */
cpumask_or(policy->related_cpus, policy->related_cpus, policy->cpus);
cpumask_copy(policy->related_cpus, policy->cpus);Again, why? It actually seems wrong. A 4 core cluster could come up with just 2 cores when the policy is added. But the related CPUs would be 4 CPUs.
Firstly, the patch hasn't changed anything at all. related_cpus was empty until this point, and orring or setting it with ->cpus will result in the same output.
I was under the impression that the CPUfreq drivers were expected to fill in related_cpus and the or-ing was a safety net. If that's not the case, then this change is fine.
Secondly, this is what we always wanted. related_cpus should contain the mask of all possible CPUs for that cluster.
I think the confusion was that I thought the drivers are supposed to do this. If this doesn't mess up other CPUfreq drivers that I'm not familiar with, then I don't have concerns.
Can you still explain the why in the commit text though? If it's just that related_cpus is always empty and copying is more efficient than or-ing, then mention that?
Thanks, Saravana