power software i perfmgmt processor lpar.pdf


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

Page 1...5 6 78964

Text preview


STG Cross Platform Systems Performance
Maybe later – perhaps via DLPAR (Dynamic LPAR) - Partition A gets told that it gets to have more
physical cores or must instead free up a few; the point is that a partition’s fixed view of its resources can
change. Partition A might even, on its own, temporarily give up the use of one or more cores for the
benefit of one or more other partitions or even energy usage. The partition’s Task Dispatcher is flexible
enough to handle these changes. Partition A’s Task Dispatcher is itself virtualizing even the number of
its cores.
Since the reality is that you don’t really know upon which core each of your tasks executes, Processor
Virtualization allows the partition’s processor cores to be further abstracted as “Virtual Processors”.
This abstraction allows us to think of each Virtual Processor as not necessarily tied to any particular core
in the system. The partition’s Task Dispatcher dispatches tasks instead to Virtual Processors, not cores.
The Virtual Processor can be thought of as being assigned to a core shortly thereafter.
In practice, though, dedicated-processor partition’s Virtual Processors really are tightly tied to particular
cores and do have some longer-term persistence to cores. A task assigned to a Virtual Processor really is
also being assigned to some particular core; using the same Virtual Processor later typically does mean
using the same core as well. Even so, these Virtual Processors can and do move, just not particularly
frequently.
A shared-processor partition’s Virtual Processors, though, might be thought of as having only shortterm persistence to a core. Unlike dedicated-processor partitions having persistent association to some
specific cores, the shared-processor partition’s Virtual Processors are all sharing the processor core
resources of something called the “Shared-Processor Pool”. It is true that even a shared-processor
partition’s Virtual Processor can remain attached to a core for quite a while, but your general mindset
ought to be that there is no long term persistence between a Virtual Processor and any particular core and
the processor cache residing there.
There are times when there are many more dispatchable tasks than there are “processors” for them all to
execute. When that happens, the partition’s tasks take turns executing. The same thing happens with the
cores of the Shared-Processor pool; the cores of the Shared-Processor pool get shared by potentially many
more active Virtual Processors. Just like tasks waiting their turn for processors, whenever there are more
active virtual processors than there are cores in this pool, Virtual Processors must take turns to execute on
the pool’s cores. Just like tasks switching on and off within a processor, for any shared-processor
partition a virtual processor’s persistence to a core can be quite temporary. A waiting Virtual Processor
may get assigned to the very next available core, no matter its location (or of the core where the Virtual
Processor last executed).
Even dedicated-processor cores might be idle; they don’t always have tasks dispatched to them. Same
thing can be true for Virtual Processors. Any Virtual Processor might be “inactive” because there are no
tasks dispatched there. For dedicated-processor partitions, this can – but not always – mean that the
associated core is going unused. For shared-processor partitions, this simply means that the empty
Virtual Processor is not assigned to any core at this time. Being inactive, it is also not competing with
active Virtual Processors for the use of the Shared-Processor pool’s cores.
Assigning one or more tasks to a Virtual Processor makes it “active”. We would want that Virtual
Processor to be attached to a core quickly thereafter. Conversely, when the Virtual Processor’s last task
ceases its execution and leaves its Virtual Processor (i.e., making it inactive), the Virtual Processor
quickly frees up that core. This active period – the time during which the Virtual Processor persists on a
core - can be very short, perhaps no longer than between a task’s pair of page faults or lock conflicts.
Such wait events temporarily remove a task from assignment to a Virtual Processor and, so, a Virtual
Processor from executing on a particular core. When a Virtual Processor without tasks is dispatched

POWER7 Logical Partitions

7