big.LITTLE switching 29 Oct 2012 Nicolas Pitre, Dave Martin

Nico:

  • Two approaches to big.LITTLE switching:
    1. either little cores active, or big cores active - not both at once
    2. all cores can potentially be active

Dave:

  • CPU life-cycle: 4 states
    1. up
    2. going down
    3. down
    4. coming up
  • Cluster shutdown: All CPUs shutting down must
    1. disable L1 allocation
    2. flush dirty L1 content
    3. disable CPU-level coherency
    4. power itself down

When all CPUs are shut down, the "last man" CPU can shut down the cluster (3 more steps)

Nico:

  • Last Man Challenges
    • Last Man has to perform a sequence of actions without interference from other CPUs
    • Other CPUs can wake up at any time.
    • LDREX/STREX only work with cached memory
    • Flushing L2 takes time
    • Other CPUs can be at various stages of shutdown

Peter De Schrijver: why not make CPU0 always the "Last Man" - could be easier? Also may be needed for secure mode. Dave/Nico: did not want to impose any artificial restrictions on the scheduler.

More challenges:

  • Which CPU is the Last Man?
  • How does the Last Man know the other CPUs are really down
  • How to avoid races with CPUs coming up?
  • etc.
  • Races everywhere

Dave:

  • Cluster life-cycle:
    • Similar to CPU life-cycle, but cluster caches need to be managed
    • Actual cluster life-cycle: six states rather than four
  • Several platform code helper functions
    • several functions beginning with bL_*

    • various bits of code under arch/arm
  • Managing cluster startup:
    • "First Man" must invalidate cluster-level (L2) cache, if needed
    • enable CCI snooping,
    • resume kernel execution
  • Other CPUs must wait until the first man has set up the cluster
  • Choosing the First Man:
    • Lightweight mutual exclusion "vlocks"
    • CPUs vote for themselves by storing their ID to a common location in memory
    • (not really an "election", more of a "race")

Nico:

  • Kernel API:
    • hides hardware specifics from the kernel
    • bL_cpu_power_up(), bL_cpu_power_down(), bL_cpu_powered_up()
      • relationship between this API and latency constraint?
        • how to indicate whether the cluster should be powered down or not?
        • Dave: could add a flag to the API to indicate whether to shut down the cluster?
  • Status of the code
    • currently only implemented on the ARM Fast Model
    • Still under validation on TC2
    • Nico's Linaro git -- branch is bL_cluster_pm

Questions:

  • How much of this can be reused for multi-cluster shutdown through cpuidle e.g. in the b.L MP case?
  • Should cpuidle deal with cluster synchronisation or leave those details to the low-level arch code
  • PSCI interaction

WorkingGroups/PowerManagement/Archives/ConfNotes/2012-10-Connect-Copenhagen/ArmShutdown (last modified 2013-08-21 12:46:43)