OK .. maybe Cathrine M. will chime in I can't remember everything we tried, but she takes notes. If I remember correctly nothing worked better than 1 CPU. I set share manually and let VMRMSVM do it dynamically. I think VMRMSVM did a better job overalll than I did manually.
On Wed, Sep 29, 2010 at 5:59 PM, Tony Thigpen <[email protected]> wrote: > IBM has said many, many times to never, never use more than 3 CPU's with > VSE, and even 3 is be bad with most work loads. This is due to the > overhead of the Turbo-Dispatcher. With 4 you were spinning the > dispatcher more than servicing the jobs. > > Try your job with just 2 CPUs. > > Tony Thigpen > > -----Original Message ----- > From: Tom Huegel > Sent: 09/29/2010 02:54 PM > > I know you are a smart guy Rob, but I beg to differ with you on this > point. > > At least where VSE is concerned. > > I have done this and can reproduce results at will (that is if I stilled > > worked there). > > Environment: > > 4 CPU z890. > > 8 gig real memory. > > z/VM 5.4 > > 7 production VSE's > > VSE 2.7 > > z/VSE 3.1 > > > > 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. > > > > > > > > > > On Wed, Sep 29, 2010 at 11:16 AM, Rob van der Heij > > <[email protected] <mailto:[email protected]>> > wrote: > > > > On Wed, Sep 29, 2010 at 7:30 PM, Frank M. Ramaekers > > <[email protected] <mailto:[email protected]>> wrote: > > > > > > This was stated on the z/VSE LISTSERV, can someone confirm (or > > deny) it? > > > > > Here is a quick tip. When running under VM with multiple VSE's it > > is usually NOT a good idea to define multiple CPU's to VSE and > > expect turbo dispacher to handle them. Why? Because z/VM will not > > dispach a VSE unless it has ALL requested CPU available. Often VSE > > could be running but is waiting for z/VM to find a secind free CPU. > > > > As stated here, we can simply conclude and demonstrate that this > claim > > is not true. The more interesting part is to understand which > > statement *is* true and how that led to this rumor ;-) > > > > In general, it's a bad idea to have more virtual CPUs than you can > get > > from z/VM when you have workload to use them. The total number of > > logical CPUs in z/VM is an upper bound for what you can get, but when > > you run 100 Linux guests on 5 IFLs, it's unlikely you find a guest > > have all its 5 virtual CPUs dispatched at the same time. > > > > One of the challenges with virtualized multi-processor guests is > about > > locking. When the virtual CPU holding the lock is not dispatched, the > > other virtual CPU ends up spinning waiting for the other virtual CPU > > to free the lock (which does not happen because you're burning a CPU > > spinning). To avoid that, the guest OS uses a "voluntary time slice > > end" DIAG44 to give up running and expect the other virtual CPU to > get > > time to free the lock. Linux is even using a later version of that to > > tell z/VM which virtual CPU should be put in front of the queue (with > > more than 2 virtual CPUs "other" is a bit vague). I don't know how > > much locking is done in VSE. > > > > Another aspect is about SMP. Linux is "symmetrical" and does not care > > which virtual CPU runs what. Some Operating Systems deal with > > serialization by "master only" tasks. z/VM used to have a lot of that > > in ancient past, and got rid of almost all now. When the guest OS > > needs some work to run on one particular CPU (the master) but > > dispatches work on both virtual CPUs, you can't pick which one is > > dispatched first by z/VM. The question would be whether VSE has much > > master only work. > > > > Rob > > -- > > Rob van der Heij > > Velocity Software > > http://www.velocitysoftware.com/ > > > > >
