Skip to main content

IBM Systems  >   System z  >   z/VM  >  

N-way, CMOS, and Master Processor Performance Considerations

Last Updated 3 April 1997

There are a few considerations to keep in mind when moving a VM/ESA system to a larger N-way configuration or a configuration where the individual processors are slower than the current system. This can be the scenario for certain migrations to new CMOS processors. For for details on VM/ESA and N-way configurations see the VM/ESA Greater N-way Thoughts presentation.

N-way Considerations

MP Factor - this refers to the efficiency losses in managing more and more processors. The VM/ESA MP Factor is very good, greater than 0.85 for all the scenarios I looked at and often greater than 0.90. This means that running VM/ESA on a 6-way would provide more than 85% of the capacity of 6 times the capacity of a single processor.

There is no UP gen for VM/ESA, unlike the 370 feature. This means there is a bit more overhead when running on a single processor, but provides for better efficiency in n-way configurations.

Areas limited by a Single Processor

In an n-way configuration, a non-MP work component is limited by the resources provided by a single processor. The following two cases illustrate this.

Case 1

Non-MP server virtual machine - the majority of server virtual machines implemented in VM are not MP capable (that is if you create a virtual MP machine with 2 or more virtual processors, the application is not capable of running work on both processors at the same time). This can be a limiting factor. For example, if you have an SQL/DS server machine that makes up 25% of the workload in terms of CPU cycles, it will be constrained on a 5-way processor. On the 5-way, 20% (1 processor out of 5) is the max the SQL server could access. In these cases, alternatives may include:

  • duplicating servers: RACF can have multiple SVMs
  • splitting the workload: create 2 SQL SVMs with separate data bases instead of having all the databases in one.
  • move some work off the server: VSCS can run in same virtual machine as VTAM or in a separate virtual machine.

    Case 2

    Master Processor - one of the ways CP serializes work is with the concept of a master processor. There is one and only one master processor on a system (though it can change at times). Just like a single non-MP server virtual machine, it is limited to a single processor. So if 15% of the workload is master only, the system will not fit comfortably on a 10-way where it is limited to 10%. Measuring master processor is difficult. To bound the impact, collect data on processor usage for master and alternates in the components of Emulation time and non-emulation time (CP and System).

                          Master non-emulation time
      upper bound  =  ------------------------------
                         Total cpu time on all processors
     
                       Master non-emulation - avg(alternate non-emulation)
      lower bound  =  ---------------------------------------------------
                            Total cpu time on all processors
     
      For example, consider a 6-way processor with following CPU breakdown
         Proc      Total%   Non-Emul% Emul%
          0         95%      35%       60%       ( master processor )
          1         94%       8%       86%
          2         94%      11%       83%
          3         95%       8%       87%
          4         93%       8%       85%
          5         95%       9%       86%
     
        upper = 35/(95+94+94+95+93+95) = 35/566 =  6.2%
     
        lower = (35- ((8+11+8+8+9)/5))/566 = (35 - 8.8)/566 = 4.6%
    

    So master processor is between 4.6 and 6.2% of the workload, so the system could run okay on a 15-way, but have problems on a 20-way.

    Equal MIPS = more processors * slower processors

    In this type of conversion, make sure that the master and single server virtual machine considerations listed above are checked.

    Realize that instructions for individual jobs will take longer. However, processor time is often just a small component of response time.

    Watch out for increases in other resource requirements because of transactions running longer. For example, an application that is somewhat compute bound will take longer to complete. Therefore, the pages associated with that application will need to be in storage longer. Moral: Provide sufficient resources to absorb any queueing caused by slower processor.


    Back to the Performance Tips Page