First, IBM has never measured this for z/VM, their resources devoted to
things like LSPR for VM are long gone. So you are either getting a
sale's person's guess, or a z/OS guess and I guess they guess different?
"Amdahl's Law of Multiprogramming" from a software perspective states
that a system's thruput (in regards to adding processors) is governed by
the amount of code that is single threaded. z/VM has done a very good
job of getting code off of the master processor, and reducing or
eliminating locking, and Linux workloads unless very storage constrained
with lots of emergency scans don't abuse the master.
With z/VM's affinity mechanism with the Processor Local Dispatch Vector
where one virtual machine block is associated with a processor, the
processor cache is also better utilized. The association dies if there
are idle processors looking for work, in which case losing a cache is
not important because there are extra processors sitting idle looking
for work.
And there is the other option of multiple lpars with dedicated IFLs, to
reduce impact of dropping caches.
Best guess - we want ibm to lower the prices so agree with ibm that 359
is the right number, in planning, MY "guess" is that it would be VERY
MUCH higher.
But the reality is that with the current storage problems that IBM
software group is giving us with their polling in WAS, DB2, Domino and
SAP are going to keep this a non-problem for a while. (Though DB2 has
very recently made very good progress toward becoming virtual friendly).
Currently "my guess" is that until ibm fixes their software you
can't/won't buy enough real storage to support 60 z10/xx processors.
Marcy Cortes wrote:
I'm getting conflicting answers from IBM.
How does VM scale with regards to multiprocessors? In the z/OS world the 1st z/10 engine
is like 900 something MIPS and the 60th on the box is something like
359. Does z/VM hosting
Linux suffer the same fate? (z/OS per engine pricing actually goes down
to compensate for this,
z/VM's does not).
Marcy
"This message may contain confidential and/or privileged information. If you are not
the addressee or authorized to receive this for the addressee, you must not use, copy,
disclose, or take any action based on this message or any information herein. If you have
received this message in error, please advise the sender immediately by reply e-mail and
delete this message. Thank you for your cooperation."
