On Tuesday, 02/03/2009 at 09:34 EST, "Schuh, Richard" <rsc...@visa.com> wrote: > I would expect that some would challenge your conclusion based on the > idea that the MP effect does not even appear unless you are running at > or near capacity. If I have two cpus or IFLs and 1.1 cpu's worth of > demand, will I notice the MP effect? Probably not. I probably will see a > better service level than when I was trying to service the same demand > with only 1 cpu. The question is, if n tasks causes a single engine to > run at 100%, will 2 engines be able to service 2n tasks as well as 1 > serviced n? I think that under normal circumstances, the answer is that > the 2 engine machine will only be able to service somewhat less than 2n.
You ask a question that has two answers. Yes and No. :-) If you give the system another CPU, it takes cycles (time) to manage it and coordinate activities with it. Those cycles are lost in the Void. So, no, there cannot be a linear scaling of *service* capacity compared to *CPU* capacity (as a function of the number of CPUs, not their size). But I took from Barton's post that if you look at the world from a business point of view (the SLA) rather than engineering, then the answer may be "Yes". Since no sane SLA would assume 100% CPU consumption, you can still meet your SLA, even in the face of non-linear growth of service capacity because you have built-in "slack" in the SLA. Sure, there's some point at which the MP effect will consume the slack. That's one of the reasons a specific VM release will support only 'n' processors. Not because we can't actually run on more than n, but because we feel the MP effects begin to overwhelm the added service capacity. (The "event horizon" of CPU scalability. Beware the tidal forces as you approach it.) Of course, the "MP effect" is a vague term that means different things to different people. Even at the hardware level another CPU is going to engage various serialization mechanisms present in the box. E.g. memory access across books. Alan Altmark z/VM Development IBM Endicott
