power software i perfmgmt processor lpar.pdf


Preview of PDF document power-software-i-perfmgmt-processor-lpar.pdf

Page 1...7 8 9101164

Text preview


STG Cross Platform Systems Performance
of your application. Decreasing response time, when high for this reason, might require more compute
capacity (e.g., more cores).
Contrasting these observations with shared-processor partitions, getting a task to execute there is
occasionally a two step process;
1. First dispatch a task to a virtual processor (which might itself introduce CPU queuing delays), then
2. Attach a Virtual Processor to a physical core to execute the task’s instruction stream; this can also
introduce a delay when there are too many active Virtual Processors contending for the available
cores.
To be more complete, when a task gets dispatched to a POWER7 Virtual Processor, the Virtual Processor
will be in one of the following states:
• Already active and attached to a core, executing fewer than four other tasks on an SMT4 core. The
new task gets to execute immediately here without delay.
• Already in an active state, but waiting for an available core (i.e., all of the shared-processor pool’s
cores already have Virtual Processors assigned). The new task dispatched to this Virtual Processor
waits because its Virtual Processor has to wait.
• In an inactive state (i.e., no tasks yet assigned there), the one newly dispatched task makes the Virtual
Processor active, but
o The newly active Virtual Processor gets immediately assigned to an available core (so the
new task gets to immediately execute),
o All of the shared-processor pool’s cores are busy (so the new task continues to wait to
execute).
You already know that tasks can experience queuing delays. Here you also see that for shared-processor
partitions there is a related effect which is a function of the over-subscription of active virtual processors
for the cores of the shared-processor pool.

Figure 3 - – Virtual Processors – Dispatching Partitions

POWER7 Logical Partitions

9