On 09/05/14 20:29, Mark Brown wrote:

On Fri, May 09, 2014 at 07:57:55PM +0100, Sudeep Holla wrote:

quoted

On 09/05/14 18:50, Mark Brown wrote:

quoted

quoted

Given that the code isn't invasive I think the expediency tradeoff is OK
for mainline, it's easy enough to get rid of when we come up with
something better but in the meaintine it helps actual systems work
better in mainline - if we didn't have the ARM implementation already I
think it'd be different but we do.

quoted

I disagree, I don't see a real urgency for this on ARM64. Even on ARM32, no
single platform other than TC2 is using this(at least as I see in the mainline).

quoted

If some real platform that needs this support urgently, then we can think of
similar short-term solution as part of adding support for cpufreq on that
platform. Do you know any platform that needs this right now ?

There's the big.LITTLE Exynos devices, at least the 5410 has shipped in
product using IKS I believe and so should've been using the big.LITTLE
cpufreq driver to do the cluster switching; I think some 5420 systems
were doing the same.  Or reimplementing it which would just be sad.
There's some other non-public devices I am aware of - the whole reason I
wrote this series was for those.

Correct all these are 32-bit platforms which are now in process of upstreaming.
So far they had their own driver and never used the arm-big-little driver.
And this current series deals with 64-bit platforms.

quoted

quoted

Perfect can be the enemy of good (or at least adequate), one of the
problems I'm seeing right now with convincing people to work with
mainline is that people are missing lots of important functionality when
they look at mainline.

quoted

Ok fair enough. But we can take some time and see if we can workout better
solution rather than jumping to add interim solutions when is unlikely to be
used on any real platform.

There are real users who want to use this fairly urgently.  I can't be
specific, sorry.

That's fine, I understand. But the main argument is that if these platforms
will not add support for cpufreq upstream anytime soon, I don't see any value
in rushing to this short term solution.

quoted

quoted

Personally the solution I'd rather see is cpufreq-cpu0 extended to
handle shared clocks which would remove the need to use the big.LITTLE

quoted

Ideally yes. IIUC it has dependencies on CPU0 and I have not looked that
driver and all of its users to judge how feasible is that. At-least we can
have cpufreq-cpu0 for all single cluster systems w/o support for per-CPU DVFS
and another which can handle multi-cluster systems(with or w/o per-CPU DVFS).

quoted

Just a thought...

It's not clear to me that having multiple clusters should require a
different driver, the single cluster case is just a specialisation of
the multicluster one as far as I can see.  It's possible I'm missing
something though.

No you are correct, but that change would require lot of changes and testing.
So my proposal above is just first step to avoid any new drivers and then we
need to merge it with cpufreq-cpu0.

I have to confess I didn't look in detail at cpufreq-cpu0 to make sure
it's the best place to start from but it looks clean and does have the
regulator stuff, though it's probably better to say that the goal is to
merge that and the big.LITTLE driver.

Me either, hence I didn't want to comment much on merging everything to
cpufrq-cpu0. Need to understand all the platforms using it so that generic 
solution based on clocks continues to work.

quoted

quoted

directly connected to their clustering.  Clustering is important to the
scheduler and an understanding of the power and clock sharing
constraints that come along with clusters is going to be required there
as part of energy aware scheduling but I'm not seeing any obvious reason
for the frequency scaling driver to know about this, even with cpufreq
governors it's mostly the clock sharing.

quoted

Both CPUFreq and Energy aware scheduling need understanding of clock
sharing. Both have similar goals(save power with little or no performance
degradation), but EA scheduler will be more efficient(both in terms of power
and performance).

quoted

Governors need this knowledge of sharing as it affects the load calculation.
(IIRC maximum load of all the cpu sharing clocks is taken)

Yes, definitely with respect to the clocks - my point was more about the
clustering bit (which is related to but not 100% tied to clocks).

Ok, that makes sense.

Regards,
Sudeep