IBM eServer zSeries 900 Technical Guide

22 IBM eServer zSeries 900 Technical Guide

򐂰 There are 6 PUs per cluster.

򐂰 Each SCE has 2 SD chips, resulting in an 8 MB L2 cache per cluster.

򐂰 There are 2 memory buses.

򐂰 There are 2 memory cards, resulting in up to 32 GB of memory.

All z900 12-PU server models use the CMOS 8S PU chips running at 1.3 ns.

A complete z900 12-PU system has 12 PUs, 16 MB L2 Cache, 4 MBAs, 2 Memory cards

allowing up to 32 GB, 2 CEs, 2 ETRs, and up to 24 1-GB/s STIs.

2.2.3 Processing units

One of the most important components of the z900 server is the Processing Unit (PU). This is

where instructions are executed and their related data reside. The instructions and the data

are stored in the PU’s high-speed buffer, called cache Level 1 (L1). As shown later on this

chapter, each PU has two individual processors inside and the instructions are executed twice

in parallel, at the same time, on both internal processors. This dual processor design allows a

simplified error detection process.

Each Processing Unit is contained on one processor chip. All the PUs of a z900 server reside

in a MultiChip Module, which is the heart of the system. An MCM can have 12 or 20 PUs,

depending on the model. This approach allows a z900 server to have more PUs than required

for a given initial configuration. This is a key point of the z900 system design and is the

foundation for the scalability of a single system.

All processor chips on a z900 model are physically identical, but a PU can have multiple

functions, one at a time. The function that a PU will have is set by the Licensed Internal Code

that is loaded. This is called

PU assignment and is always done during a z900 system

initialization time (Power-On-Reset). Unassigned PUs are called

spare PUs.

This design brings an outstanding flexibility to the z900 servers, as any processor chip can

assume any PU function. This also has an essential role in z900 system availability, as these

PU assignments can be done dynamically, with no server outage, allowing:

򐂰 Concurrent upgrades

Except on fully configured models, concurrent upgrades can be done by the LIC, which

assigns a PU function to a previously unassigned (spare) PU. No hardware changes are

required and it can be done via Capacity Upgrade on Demand (CUoD), Customer Initiated

Upgrade (CIU) or Capacity BackUp (CBU).

Concurrent upgrades are described in Chapter 6, “Capacity upgrades” on page 205.

򐂰 PU sparing

In the rare case of a PU failure, the failed PU’s function is dynamically and transparently

reassigned to a spare PU. See more details about PU sparing in “Processing Unit sparing”

on page 28.

A PU can be assigned as:

򐂰 A Central Processor (CP)

All general purpose and capacity models have at least one CP.

򐂰 An Integrated Facility for Linux (IFL)

IFLs are optional features for general purpose and capacity models.

򐂰 An Internal Coupling Facility (ICF)