Lines Matching refs:cluster
5 cluster setup and teardown operations and to manage hardware coherency
28 cluster-level operations are only performed when it is truly safe to do
33 are not immediately enabled when a cluster powers up. Since enabling or
37 power-down and power-up at the cluster level.
47 Each cluster and CPU is assigned a state, as follows:
63 DOWN: The CPU or cluster is not coherent, and is either powered off or
66 COMING_UP: The CPU or cluster has committed to moving to the UP state.
70 UP: The CPU or cluster is active and coherent at the hardware
74 GOING_DOWN: The CPU or cluster has committed to moving to the DOWN
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-
88 To help distinguish the CPU states from cluster states in this
90 and a CLUSTER_ or INBOUND_ prefix for the cluster states.
109 cluster setup and
153 cluster is set up and coherent. If the cluster is not ready,
155 cluster has been set up.
158 Conditions: The CPU's parent cluster must be in CLUSTER_UP.
159 Trigger events: Transition of the parent cluster to CLUSTER_UP.
200 A cluster is a group of connected CPUs with some common resources.
201 Because a cluster contains multiple CPUs, it can be doing multiple
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
221 "inbound" state: The state of the cluster on the inbound side.
228 states for the cluster as a whole:
248 only involve changes to the "cluster" state.
253 outbound CPU has put the cluster into the CLUSTER_DOWN state).
256 which exact CPUs within the cluster play these roles. This must
262 cluster can actually be powered down.
268 COMING_UP in the basic model). The second path avoids cluster
280 <cluster state>/<inbound state> (<transitioner>)
300 In this state, an inbound CPU sets up the cluster, including
301 enabling of hardware coherency at the cluster level and any
305 The purpose of this state is to do sufficient cluster-level
306 setup to enable other CPUs in the cluster to enter coherency
310 Conditions: cluster-level setup and hardware coherency complete
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
335 The cluster will remain in this state until a policy decision is
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
351 cluster-level coherency.
354 should check the inbound cluster state for asynchronous
362 Conditions: cluster torn down and ready to power off
378 The cluster is (or was) being torn down, but another CPU has
379 come online in the meantime and is trying to set up the cluster
384 a) back out of teardown, restoring the cluster to the
387 b) finish tearing the cluster down and put the cluster
389 set up the cluster again from there.
393 the cluster is not really going to be powered down.
399 Conditions: cluster-level setup and hardware
404 Conditions: cluster torn down and ready to power off
411 The CPU which performs cluster tear-down operations on the outbound side
414 The CPU which performs cluster setup on the inbound side is commonly
423 When shutting down the cluster, all the CPUs involved are initially
433 attempts to play the first man role and do the cluster-level
468 the case of an aborted cluster power-down).
472 is needed for safe transitions at the cluster level.
474 A cluster transitions from CLUSTER_DOWN back to CLUSTER_UP via
485 extended by replicating the cluster-level states for the
487 rules for the intermediate (non-outermost) cluster levels.