• Home
  • Raw
  • Download

Lines Matching full:state

48 Each cluster and CPU is assigned a state, as follows:
71 The CPU or cluster has committed to moving to the UP state.
77 level. A CPU in this state is not necessarily being used
82 state. It may be part way through the process of teardown and
87 The CPU states are described in the "CPU state" section, below.
89 Each cluster is also assigned a state, but it is necessary to split the
90 state value into two parts (the "cluster" state and "inbound" state) and
92 CPUs in the cluster simultaneously modifying the state. The cluster-
93 level states are described in the "Cluster state" section.
96 discussion, the state names are given a `CPU_` prefix for the CPU states,
100 CPU state
137 next state as a result of making local progress only, with no
142 A CPU reaches the CPU_DOWN state when it is ready for
143 power-down. On reaching this state, the CPU will typically
147 Next state:
162 then the CPU will wait in the CPU_COMING_UP state until the
165 Next state:
172 Refer to the "Cluster state" section for a description of the
173 CLUSTER_UP state.
177 When a CPU reaches the CPU_UP state, it is safe for the CPU to
182 Note that the definition of this state is slightly different
189 The CPU remains in this state until an explicit policy decision
192 Next state:
201 While in this state, the CPU exits coherency, including any
205 Next state:
213 Cluster state
221 In this discussion, the "outbound side" is the view of the cluster state
223 view of the cluster state as seen by a CPU setting the CPU up.
226 that a CPU which is setting up the cluster can advertise its state
228 reason, the cluster state is split into two parts:
230 "cluster" state: The global state of the cluster; or the state
237 "inbound" state: The state of the cluster on the inbound side.
264 only involve changes to the "cluster" state.
267 involve changes to the "inbound" state, except where there is no
269 outbound CPU has put the cluster into the CLUSTER_DOWN state).
277 CLUSTER_DOWN/INBOUND_NOT_COMING_UP is the only state where the
289 is trivial and merely resets the state machine ready for the
294 The next state in each case is notated
296 <cluster state>/<inbound state> (<transitioner>)
303 Next state:
317 In this state, an inbound CPU sets up the cluster, including
322 The purpose of this state is to do sufficient cluster-level
326 Next state:
340 This is a transient state, leading immediately to
344 Next state:
358 The cluster will remain in this state until a policy decision is
361 Next state:
372 must wait in this state until all CPUs in the cluster are in the
373 CPU_DOWN state.
375 When all CPUs are in the CPU_DOWN state, the cluster can be torn
380 should check the inbound cluster state for asynchronous
411 If the outbound CPU observes this state, it has two choices:
414 CLUSTER_UP state;
417 in the CLUSTER_DOWN state; the inbound CPU will
490 CPU_GOING_DOWN state.
493 state.