Edward E. Jaffe wrote:
Schramm, Rob wrote:

Why isn't there an option to run multiple groups of shared CPUs on a
single box?

If I can run 54 processors on a box.. it would seem to make more sense
to run groups of shared processors and setting up lpars to share them
appropriately  than trying to setup 54 procs to be shared across a
number of lpars.

For example lets say I have 1 box.  I need 2 lpars with about 10 cpu's
(BIG1 & BIG2), 2 lpars with 2 cpu's (SML1 & SML2), and 3 lpars with 4
cpu's (MED1, MED2 & MED3).   So I could setup a cpc1 with 12 cpus (for
BIG1 & SML1), cpc2 with 12 (for BIG2 & SML2) and cpc3 with 12 (MED1,
MED2 & MED3).  Thereby reducing CPU software/hardware overhead.

Or am I missing something obvious that makes it "not a good idea"?

I honestly don't see how your idea would reduce hardware/software overhead, especially given existing and constantly improving algorithms for controlling physical to logical CP assignment. (Cooperation between z/OS WLM and PR/SM i.e., IRD, etc.) Perhaps you could better explain your rationale.

Furthermore, hard partitioning of physical resources in this way (let's call them PPARs) seems like it would become problematic -- leading to situations in which physical resources needed for the LPARs running in one PPAR become constrained while physical resources in another PPAR are simultaneously underutilized. This idea seems contrary to the very notion of on-demand resource provisioning -- not unlike going back to having two separate machines. IRD can't help you there!


IMHO it does make a sense.
1. You can share processors for systems which do not support more than x (16) CPs, or support them badly, or there are tools installed which do not support or... 2. You can assign CPgroup1 to prod LPARs, and CPgroup2 to non-prod. Or, you assign group1 to Customer1 LPARs, and group2 to Customer2 LPARs. Workload is balanced only within Customer "sandbox". Especially useful when whole-CP granularity isn't enough.

Of course it is only requirement justification, not a method how to do it.

--
Radoslaw Skorupka
Lodz, Poland

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to