Hi guys, On Thursday 05 Nov 2020 at 15:25:53 (+0100), Vincent Guittot wrote: [..] > > > - Because of hardware co-ordination of otherwise co-ordinated CPUs, > > > few things break. Thermal and EAS are some of the examples and so > > > you are trying to fix them here by proving them the missing > > > information again. > > > > Correct. And for this I have proposed two ways. > > > > > > > > - One other thing that breaks with this is freq-invariance in the > > > scheduler, as the scheduler won't see the real frequencies the > > > various CPUs are running at. Most of the hardware we have today > > > doesn't have counters, like AMUs, not sure if all future ones based > > > on SCMI will have that too, so how are they gong to be fixed ? > > > > > > > Correct. freq-invariance without counters is trying to do its best based on > > the > > information it has available. It definitely relies on the knowledge of the > > v/f > > domains to work at its best so I think in the case of per-cpu it will > > follow the > > same approach as others being affected (EAS, thermal). > > As frequency invariance has same problem as EAS and Thermal it would > be good to see the solution as part of this proposal like EAS and > Thermal >
I think I was waiting for a consensus on patch 3/3, although I believe the discussion at [1] tended towards option 2: "each driver to store internally the performance dependencies and let the driver directly provide the correct cpumask for any consumer." The alternative was option 1: "add a new dependent_cpus cpumaks in cpufreq_policy", as Nicola mentioned in the commit message for 3/3. If the choice is clear, I'm happy to take the FIE fixes in a separate set. Thanks, Ionela. [1] https://lore.kernel.org/linux-arm-kernel/[email protected]/ > > > > > And if we even have to fix this (freq invariance), what's hardware > > > coordination giving us that makes all this worth it ? > > > > I suppose this is more a generic question for all the platforms running > > with h/w > > coordination, but for our case is that the f/w will take care of the > > performance > > optimizations for us :) > > > > > > > > Sorry about the long list :) > > > > No problem at all. Thank you for your time on this and I hope I have made > > bits > > clearer. > > > > Nicola > > > > >
