On 27-01-17, 19:37, Saravana Kannan wrote:
Viresh,
If I'm not mistaken, Steve's change for allowing changes to remote CPUs was limiting it to slow path
Not completely.
and also limiting it to only CPUs within the same cluster.
There are two cases really:
- Remote call for a CPU in same policy
This isn't considered as remote in this series and will be taken care of directly from sugov_update_commit().
- Remote call for a CPU from another policy
This is considered remote. And irq-work is shot from sugov_update_commit() on the target CPU. Now we again check if fast path execution is possible in the irq-work and don't involve the RT thread in that case.
Otherwise, we take care of it as slow path code via the RT thread.
Our CPU scaling code doesn't have any such relation. We can set the frequency of any CPU from any CPU. I think it'll be best to push this detail to the CPUfreq driver. Maybe we can have a flag where the CPUfreq driver says it wants to do remote CPU setting or not. And then we can let the driver do the filtering as they see fit.
You want to allow frequency setting from a CPU in policy X to a CPU in policy Y? And of course that will make sense only for the fast path.
On 01/23/2017 03:21 AM, Viresh Kumar wrote:
<I'm able to read your email, but it is getting garbled for some reason when I try to reply. Deleted it.>
Strange, I sent it with plain git send-email. Shouldn't be a problem with the mail at least.
-- viresh