IBM eServer zSeries 900 Technical Guide

28 IBM eServer zSeries 900 Technical Guide

2.2.5 Processing Unit assignments

Processing Unit (PU) assignments are made at the Initial Microcode Load (IML) time during a

Power-On-Reset (POR).

򐂰 CPs are assigned from the lowest numbered PUs, alternating across the two clusters to

equalize load in each cluster and maximize throughput.

򐂰 SAPs are assigned from the highest numbered PUs. Optional SAPs are kept on one

cluster to minimize impact of SAP activity on L2 cache.

򐂰 IFLs and ICFs are assigned from the remaining highest numbered PUs, and are kept on

one cluster to minimize impact of IFL/ICF activity on the L2 cache.

򐂰 The two PUs associated with the alternate path from each CE are the last to be assigned

as CPs, SAPs, IFLs, or ICFs.

2.2.6 Processing Unit sparing

Transparent CP/ICF/IFL sparing

All z900 models introduced will come with at least one spare PU. CP/ICF/IFL sparing is

transparent in all modes of operation and requires no operating system or operator

intervention to invoke a spare CP, ICF or IFL processor. This function is available on all z900

servers, including the model 100 which supports sparing for all ICF features (including the

model configured with nine ICF features).

With transparent sparing, the application that was running on the failed processor will be

preserved and will continue processing on a new physical processor (one of the spare PUs),

with no customer intervention required. If there are no spare PUs available, Application

Preservation is invoked.

Application Preservation

Application Preservation is used in the case where a processor fails and there are no spare

PUs available. The state of the failing processor is passed to another active processor where

the operating system uses it and, through the operating system recovery services,

successfully resumes the task—in most cases without customer intervention.

Dynamic SAP sparing/reassignment

Dynamic recovery is provided in case of failure of the System Assist Processor (SAP). In the

event of a SAP failure, if a spare PU is available, in most cases the spare PU will be

dynamically activated as a new SAP. If there is not a spare PU available, and the CPC has

more than one CP, an active CP will be reassigned as a master SAP. In either case, there is

no customer intervention required. This capability eliminates an unplanned outage and

permits a service action, if necessary, to be deferred to a more convenient time.

Sparing rules

The sparing rules for the allocation of CPs, crypto CPs, Master SAP (MSAP), SAPs, ICFs and

IFLs are as follows:

򐂰 For crypto CPs, they are spared into their dual path spare PU if available. If the dual path

spare PU is not available, then sparing starts from the highest and continues in

descending order:

a. Spare with the non-crypto PU spares until they are all used.

b. The last resort for sparing, if a non-crypto spare is not available, is to use the other dual

path spare.