Lines Matching refs:the
4 This file documents the algorithm which is used to coordinate CPU and
8 The section "Rationale" explains what the algorithm is for and why it is
10 of the system. The other sections explain the actual details of the
17 In a system containing multiple CPUs, it is desirable to have the
18 ability to turn off individual CPUs when the system is idle, reducing
22 to have the ability to turn off entire clusters.
26 of independently running CPUs, while the OS continues to run. This
37 power-down and power-up at the cluster level.
40 based protocol for performing the needed coordination. It aims to be as
41 lightweight as possible, while providing the required safety properties.
66 COMING_UP: The CPU or cluster has committed to moving to the UP state.
67 It may be part way through the process of initialisation and
70 UP: The CPU or cluster is active and coherent at the hardware
72 actively by the kernel.
74 GOING_DOWN: The CPU or cluster has committed to moving to the DOWN
75 state. It may be part way through the process of teardown and
80 The CPU states are described in the "CPU state" section, below.
82 Each cluster is also assigned a state, but it is necessary to split the
83 state value into two parts (the "cluster" state and "inbound" state) and
85 CPUs in the cluster simultaneously modifying the state. The cluster-
86 level states are described in the "Cluster state" section.
88 To help distinguish the CPU states from cluster states in this
89 discussion, the state names are given a CPU_ prefix for the CPU states,
90 and a CLUSTER_ or INBOUND_ prefix for the cluster states.
100 This means that CPUs fit the basic model closely.
102 The algorithm defines the following states for each CPU in the system:
122 The definitions of the four states correspond closely to the states of
123 the basic model.
127 A trigger event (spontaneous) means that the CPU can transition to the
134 A CPU reaches the CPU_DOWN state when it is ready for
135 power-down. On reaching this state, the CPU will typically
152 A CPU cannot start participating in hardware coherency until the
153 cluster is set up and coherent. If the cluster is not ready,
154 then the CPU will wait in the CPU_COMING_UP state until the
159 Trigger events: Transition of the parent cluster to CLUSTER_UP.
161 Refer to the "Cluster state" section for a description of the
166 When a CPU reaches the CPU_UP state, it is safe for the CPU to
169 This is done by jumping to the kernel's CPU resume code.
171 Note that the definition of this state is slightly different
172 from the basic model definition: CPU_UP does not mean that the
174 the kernel. The kernel handles the rest of the resume
175 procedure, so the remaining steps are not visible as part of the
179 is made to shut down or suspend the CPU.
188 While in this state, the CPU exits coherency, including any
202 things at the same time. This has some implications. In particular, a
203 CPU can start up while another CPU is tearing the cluster down.
205 In this discussion, the "outbound side" is the view of the cluster state
206 as seen by a CPU tearing the cluster down. The "inbound side" is the
207 view of the cluster state as seen by a CPU setting the CPU up.
210 that a CPU which is setting up the cluster can advertise its state
211 independently of the CPU which is tearing down the cluster. For this
212 reason, the cluster state is split into two parts:
214 "cluster" state: The global state of the cluster; or the state
215 on the outbound side:
221 "inbound" state: The state of the cluster on the inbound side.
228 states for the cluster as a whole:
247 Transitions -----> can only be made by the outbound CPU, and
248 only involve changes to the "cluster" state.
250 Transitions ===##> can only be made by the inbound CPU, and only
251 involve changes to the "inbound" state, except where there is no
252 further transition possible on the outbound side (i.e., the
253 outbound CPU has put the cluster into the CLUSTER_DOWN state).
256 which exact CPUs within the cluster play these roles. This must
257 be decided in advance by some other means. Refer to the section
261 CLUSTER_DOWN/INBOUND_NOT_COMING_UP is the only state where the
264 The parallelism of the inbound and outbound CPUs is observed by
265 the existence of two different paths from CLUSTER_GOING_DOWN/
266 INBOUND_NOT_COMING_UP (corresponding to GOING_DOWN in the basic
268 COMING_UP in the basic model). The second path avoids cluster
271 CLUSTER_UP/INBOUND_COMING_UP is equivalent to UP in the basic
273 is trivial and merely resets the state machine ready for the
276 Details of the allowable transitions follow.
282 where the <transitioner> is the side on which the transition
283 can occur; either the inbound or the outbound side.
300 In this state, an inbound CPU sets up the cluster, including
301 enabling of hardware coherency at the cluster level and any
306 setup to enable other CPUs in the cluster to enter coherency
317 enabled for the cluster. Other CPUs in the cluster can safely
321 CLUSTER_UP/INBOUND_NOT_COMING_UP. All other CPUs on the cluster
332 enabled for the cluster. Other CPUs in the cluster can safely
336 made to power the cluster down.
340 Trigger events: policy decision to power down the cluster
345 An outbound CPU is tearing the cluster down. The selected CPU
346 must wait in this state until all CPUs in the cluster are in the
349 When all CPUs are in the CPU_DOWN state, the cluster can be torn
353 To avoid wasteful unnecessary teardown operations, the outbound
354 should check the inbound cluster state for asynchronous
379 come online in the meantime and is trying to set up the cluster
382 If the outbound CPU observes this state, it has two choices:
384 a) back out of teardown, restoring the cluster to the
387 b) finish tearing the cluster down and put the cluster
388 in the CLUSTER_DOWN state; the inbound CPU will
389 set up the cluster again from there.
391 Choice (a) permits the removal of some latency by avoiding
393 the cluster is not really going to be powered down.
411 The CPU which performs cluster tear-down operations on the outbound side
412 is commonly referred to as the "last man".
414 The CPU which performs cluster setup on the inbound side is commonly
415 referred to as the "first man".
423 When shutting down the cluster, all the CPUs involved are initially
425 be used to select a last man safely, before the CPUs become
433 attempts to play the first man role and do the cluster-level
438 coherency controls in the bus fabric.
454 __mcpm_cpu_going_down() signals the transition of a CPU to the
457 __mcpm_cpu_down() signals the transition of a CPU to the CPU_DOWN
460 A CPU transitions to CPU_COMING_UP and then to CPU_UP via the
462 involve CPU-specific setup code, but in the current
468 the case of an aborted cluster power-down).
470 These functions are more complex than the __mcpm_cpu_*()
471 functions due to the extra inter-CPU coordination which
472 is needed for safe transitions at the cluster level.
475 the low-level power-up code in mcpm_head.S. This
477 provided by the platform-specific power_up_setup
482 As currently described and implemented, the algorithm does not
485 extended by replicating the cluster-level states for the
486 additional topological levels, and modifying the transition
487 rules for the intermediate (non-outermost) cluster levels.
497 Distributed under the terms of Version 2 of the GNU General Public