[PATCH 2/3] arm64: Add big.LITTLE switcher stub

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

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

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.

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).

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.

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.

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.

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

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).

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.

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.

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.

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).

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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140509/02ca1d87/attachment.sig>