IBM Support

VM66154: GUEST WITH ABSOLUTE LIMITHARD LIMITED INACCURATELY

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • When a guest is performing heavy I/O it may not be limited to
    the guest's ABSOLUTE LIMITHARD SETTING.
    Not limiting a guest accurately can negatively impact other
    guest's consumption capability, particularly in a CPUPOOL.
    

Local fix

  • local patch is available upon request
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of SET SHARE LIMITHARD or CPU POOL *
    *                 limiting of guest CPU utilization            *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    ****************************************************************
    * RECOMMENDATION: APPLY PTF                                    *
    ****************************************************************
    SHARE with the LIMITHARD option and RESPOOL (CPUPOOL) limiting
    may not work correctly for all work loads.
    
    A guest with a hard limit (SET SHARE ... LIMITHARD) or that is a
    member of a CPU pool with a CPU limit (LIMITHARD or CAPACITY)
    might not be limited appropriately. While this could occur for
    several reasons, the most likely is that the guest has a high
    degree of I/O activity. While I/O is in progress, a guest holds
    a share of a lock, which prevents it from being added to the
    Limit List. As long as at least one guest I/O operation is in
    flight this condition will prevail. Eventually, when there is no
    active I/O, the guest will be limited, potentially for a long
    period of time, during which it will be completely unresponsive.
    
    In scenarios, such as the one described above, CP work
    dispatched on a guest VMDBK requires a critical lock, or more
    than one critical lock.  Each time one of the locks is obtained,
    a count of critical processes (VMDCTCRT) is incremented.  It is
    decremented when the lock is released.  The VMDBK is not limited
    when that critical count is non-zero so that release of the lock
    isn't delayed for a long time while the guest is limited.
    
    When a guest is doing things that require much CP involvement
    and that CP work frequently requires critical locks, the
    critical count can stay non-zero for an extended amount of time.
    If that happens and the guest is limited by the SHARE LIMITHARD
    option or by RESPOOL limiting, the VMDBK may be withheld from
    the limit list even though it is due to be limited.  Eventually,
    when the count goes to zero, the VMDBK will be limited for an
    extended amount of time to make up for the excess CPU it used
    when it should have been limited.  This can cause erratic
    response times from the guest and can lead to guest time-outs.
    

Problem conclusion

  • The dispatcher and scheduler are changed to dispatch CP work on
    behalf of a guest VMDBK that is being otherwise limited.  The CP
    work will be allowed to execute but the VMDBK will not be run
    under SIE.
    
    To accomplish this the actual addition of a VMDBK to the limit
    list is moved from the scheduler to the dispatcher.  The
    dispatcher will only add the VMDBK to the limit list when no
    more CP work is stacked on it.  Also, the VMDBK is temporarily
    taken off the limit list if it is being made ready because CP
    work has been stacked on it.
    

Temporary fix

  • FOR RELEASE VM/ESA CP/ESA R640 :
    PREREQ: VM65615
    CO-REQ: NONE
    IF-REQ: NONE
    FOR RELEASE VM/ESA CP/ESA R710 :
    PREREQ: VM65715
    CO-REQ: NONE
    IF-REQ: NONE
    

Comments

  • ×**** PE20/06/10 FIX IN ERROR. SEE APAR VM66400  FOR DESCRIPTION
    

APAR Information

  • APAR number

    VM66154

  • Reported component name

    VM CP

  • Reported component ID

    568411202

  • Reported release

    630

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2018-04-25

  • Closed date

    2019-05-02

  • Last modified date

    2020-12-16

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

    UM35444 UM35445

Modules/Macros

  • HCPCPA   HCPCPU   HCPDSP   HCPDSW   HCPLMC   HCPSCH   HCPSCI
    HCPSCK   HCPSRN   HCPSTK   HCPSTL   HCPSTM   HCPVMDBK
    

Fix information

  • Fixed component name

    VM CP

  • Fixed component ID

    568411202

Applicable component levels

  • R640 PSY UM35444

       UP19/05/16 P 2001

  • R710 PSY UM35445

       UP19/05/16 P 1902

Fix is available

  • Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.

[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG27M","label":"APARs - z\/VM environment"},"Platform":[{"code":"PF054","label":"z\/OS"}],"Version":"630","Line of Business":{"code":"LOB16","label":"Mainframe HW"}}]

Document Information

Modified date:
12 January 2021