+ All Categories
Home > Technology > SFO15-109: SoC idling

SFO15-109: SoC idling

Date post: 12-Apr-2017
Upload: linaro
View: 395 times
Download: 0 times
Share this document with a friend
Embed Size (px)
of 14 /14
Presented by Date Event SFO15-109: SoC / Cluster Idle Presenters Ulf Hansson, Kevin Hilman, Lina Iyer Monday 21 September 2015 SFO15
Page 1: SFO15-109: SoC idling

Presented by



SFO15-109: SoC / Cluster Idle

PresentersUlf Hansson, Kevin Hilman, Lina Iyer

Monday 21 September 2015


Page 2: SFO15-109: SoC idling

One idle to rule them all?

Kevin Hilman, [email protected]

Idle management of CPUs

&IO devices

Page 3: SFO15-109: SoC idling

Two separate worlds


● CPU idle framework● cpu_[cluster_]pm_*()● not scaling well for SMP or multi-

cluster (c.f. coupled idle states)

IO devices

● Runtime PM● auto-suspend● PM domains● generic PM domains (genpd)

Page 4: SFO15-109: SoC idling

One idle to rule them all What if…

● use runtime PM for CPUs● and CPU-connected “stuff”

○ interrupt controllers (ARM GIC)○ floating-point units○ CPU-local cache (L1$)

● model clusters with genpd○ CPUs are just “devices” in the genpd○ genpd includes shared resources (e.g. L2$)

Runtime PM

Page 5: SFO15-109: SoC idling

SoC/Cluster Idle








Page 6: SFO15-109: SoC idling

SoC/Cluster Idle - What we need

● Hierarchy and nesting● Last-man reference counting● Platform Callbacks● CPUidle and Hotplug● Relationship in DT

Page 7: SFO15-109: SoC idling

SoC/Cluster Idle - Solution

● Use genpd and Runtime PM● Describe CPUs and domains in DT

○ CPU: #power-domains = <&pd>;○ power-controller: #power-domain;

● Initialize genpd PM domains● Attach CPU devices to genpd● Add Runtime PM support for CPUIdle and Hotplug● Provide platform callbacks

Page 8: SFO15-109: SoC idling


● Mutexes used in genpd○ Solution: Optionally, spinlocks for domains

● RCU called from idle CPU○ RCU_NONIDLE()

Page 9: SFO15-109: SoC idling

Addition to genpd rules

● No change for non-IRQ Safe Domains● IRQ Safe Domain

○ Contain only IRQ Safe devices & domains

● Can you combine them (subdomains)?

Page 10: SFO15-109: SoC idling

Ran into problems, heh!

● RCU stalls observed○ Unresolved

● Runtime PM in Hotplug○ Use Hotplug notifiers for a generic solution

● Performance: Heavy weight for CPUIdle?● -RT kernel compatibility

Page 11: SFO15-109: SoC idling

Heavy weight for CPUidle?

● Additional latency*○ Last CPU Idle enter: 50 - 70 us○ First CPU Idle exit: 73 - 90 us

● Trim fat?

* Initial attempts on a 800 Mhz quad core ARM CPU

Page 12: SFO15-109: SoC idling

-RT compatibility

● Spinlocks may sleep in -RT kernel○ raw_ spinlocks can spin on -RT

● CPUs can runtime suspend/resume only their devices○ Do we need to even lock?

● Lockless Runtime PM, perhaps?

Page 13: SFO15-109: SoC idling

Next steps, discussion● genpd evolution

○ locking simplification (Ulf Hansson, merged)○ removing intermediate states (Ulf Hansson, merged)○ CPU PM domains, IRQ-safe genpd support (Lina Iyer, posted)○ etc.

● CPU PM notifiers: cpu_[cluster_]_pm_[enter|exit]()○ used for IRQ chips, floating-point units, PMUs, wakeups, etc.○ can/should we use runtime PM instead? (runtime PM callbacks instead of

notifiers)● pm_genpd_attach_cpuidle()

■ no more users? kill it. (Ulf Hansson, posted)

Page 14: SFO15-109: SoC idling

Next steps, discussion (cont)...● genpd: needs to support multiple levels

○ currently only supports on/off○ CPU/clusters have more levels (e.g. retention, C-states)○ IO devices (D-states)○ RFC by Axel Haslam (BayLibre)

● ACPI 6: low-power idle (LPI)○ supports hierarchical idle○ seems to map better to genpd than CPUidle (c.f. Fig 8-46, 6.0 spec)

● PSCI: OS-Initiated composite StateID