On Fri, Jul 14, 2017 at 10:33:20AM +0530, Viresh Kumar wrote: > On 13-07-17, 19:02, Saravana Kannan wrote: > > Honestly, this seems like such a chip/platform specific decision. There's no > > reason that one can't have a chip where you can change the frequency of any > > CPU from any other CPU. If there's such a limitation, we should let that be > > handled at the CPU freq driver level instead of having to know about any of > > that at the scheduler. Heck, at worst case, the CPU freq driver can send an > > IPI and execute that work on the CPU of interest. > > > > In all Qualcomm chipsets (well, at least the ones that have been used in > > Android devices so far), we can switch the frequency of any CPU from any > > other CPU. If we can do that even without fast switching, why wouldn't any > > theoretical fast switching be incapable of supporting this?
I spoke with Sudeep since the last email; and the proposed interface (SCMI) is a shmem/mailbox one, which can indeed change the frequency of another CPU. > > Is this a limitation specific to x86 that we are assuming all > > architectures and platforms are going to have? You are right in that x86 cannot do this. Sending IPIs is fairly expensive though :/ > The default assumption in cpufreq core is that any CPU from a policy > can change freq for that policy. Yes, we surely have cases where any > CPU can change freq of any other CPU (even in different policies). > Perhaps all ARM platforms are like that, not sure. > > And so I added a special flag for that in my previous version, but the > idea here is to get a simple solution merged first and then we can > have a separate patch later to support freq switching from all CPUs. I was going to write things about serialization here. How allowing remote updates would require extra serialization, in part inspired by your Changelog comment that says cpufreq-shared provides the required serialization. But I think that's all nonsense... That is, yes cpufreq-shared needs additional serialization, but that's not relevant for the problem at hand. The thing is, all of this cpufreq_update_*() crud is called with the relevant rq->lock held. So all those calls are already fully serialized between CPUs.
