Also... you haven't mentioned whether you adjusted the share value when you added virtual cpus to your VSE guest. Remember that each v-cpu will get only 1/n of the userid's share, which may place them at a disadvantage if competing with the virtual cpus of your other guests. So if I'm running most guests with one v-cpu at the default share of relative 100, then I'd give a 4-cpu guest a share of 400 (to put all v-cpus on an equal footing). -- Mike Harding z/VM System Support
[email protected] [email protected] [email protected] (925) 926-3179 (w) (925) 323-2070 (c) IM: VMBearDad (AIM), mbhcpcvt (Y!) The IBM z/VM Operating System <[email protected]> wrote on 09/29/2010 02:52:15 PM: > From: Rob van der Heij <[email protected]> > To: [email protected] > Date: 09/29/2010 02:52 PM > Subject: Re: z/VSE dispatch of multi-CPU under VM > Sent by: The IBM z/VM Operating System <[email protected]> > > On Wed, Sep 29, 2010 at 8:54 PM, Tom Huegel <[email protected]> wrote: > > > With VSE's using only 1 CPU (non-dedicated) I carfully selected a one hour > > job mix. > > Giving VSE's 4 CPU's (non-dedicated) the same job mix ran close to 1hr > > 20min... > > This is wall clock time, which in final analysis is the only one that > > counts. > > If you think we disagree, then I was obviously not clear enough. With > 7 VSE guests, the amount of resources each could get at any time will > be (far) less than 400% (all 4 CPUs). If more than 4 of them working, > each gets even less than one CPU worth of cycles. So one virtual CPU > will do. The drawback is that with just one virtual CPU you can not > get more than 100% of a CPU, not even when all the others are idle. > That may or may not be a true concern. > > While you're right that wall clock time is what counts, performance > measurements help you understand the difference between two > experiments and allow you to improve performance other than through > trial and error. > > Rob > -- > Rob van der Heij > Velocity Software > http://www.velocitysoftware.com/
