Hi Don,
Very insightful of you.
It is commonly believed that "there can be no instance of where lower
importance [lower priority] work can cause a higher importance level to
miss its goals, except in the case of resource groups." This belief is
mostly correct from a WLM dispatching priority assignment view. However,
this belief has been incorrect in a general sense for a very long
time. Not only can low importance work have access to other resources as
you mentioned, low importance work can temporarily be given high
dispatching priority.
As of z/OS V1R13, five categories are reported in SMF where relatively low
importance work had its dispatching priority increased or promoted to a
higher CPU dispatching priority: (1) R723ECTC (CPU time consumed while
dispatching priority was temporarily raised by enqueue management); (2)
R723TPDP (CPU time consumed while dispatching priority of work with low
importance was temporarily raised to help blocked workloads); (3) R723CPDP
(CPU time consumed while dispatching priority was temporarily raised by
chronic resource contention management); (4) R723LPDP (CPU time consumed
while dispatching priority was temporarily raised to shorten the lock hold
time of a local suspend lock held by the work unit); and (5) R723SPDP (CPU
time consumed while dispatching priority for a work unit was temporarily
raised by the z/OS supervisor to a higher dispatching priority than
assigned by WLM). Each category is used to help reduce bottlenecks or
improve overall performance of work.
Sustained processor use in these categories typically is of short
duration. However, I have data showing that enqueue promotion management
for low importance work to a high dispatching priority was several minutes
per RMF interval (more than 10 minutes in one set of data).
In many cases, CPU delays caused by promotion of dispatching priority will
be insignificant, particularly if the effects of the dispatching priority
promotion happen with LPARs having a relatively large number of
processors. However, the effects can significantly degrade performance
with a small number of logical processors assigned to an LPAR (or unparked
with HiperDispatch).
If you see performance degradation of high importance work because of CPU
Delay, you should check the values of the above SMF variables. Promoted
dispatching priority of low importance work could be the culprit.
Regards,
******
Don Deese, Computer Management Sciences, Inc.
Voice: (804) 776-7109 Fax: (804) 776-7139
http://www.cpexpert.org
******
At 12:45 PM 2/21/2013, you wrote:
Low priority work may have exclusive access to other resources (locks,
enqueues, memory, etc.) which blocks (i.e., effectively preempts) higher
priority work.
In most cases, this type of "preemption" does not last long enough to be
significant; however, when your system is on running on the edge this
effect may be significant in your particular situation.
Don
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Gerhard Adam
> Sent: Tuesday, February 19, 2013 2:46 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Low priority workload
>
> I have to disagree. I often hear this, but there's no "resources" to
> give. Other than MPL adjustments, almost all of the major WLM
> decisions are simply a matter of setting dispatching priorities. There
> can never be a situation of where a lower priority [lower DP] unit of
> work can pre-empt a higher DP unit of work.
>
> In addition, higher importance levels always have precedence in terms
> of having their goals honored, well above lower importance level work,
> so again, there can be no instance of where lower importance [lower
> priority] work can cause a higher importance level to miss its goals,
> except in the case of resource groups.
>
> In addition, WLM "predicts" the expected outcomes every 10 seconds, so
> there is no need to "know" future workload. Having excess available
> resources only ensures that those units at lower priorities have
> access. High DP work isn't subject to resource availability unless
> there are an excessive number of competitors at the same or higher
> levels. If all the processing power is used by high DP work, then
> there is nothing that can be done except incur delays, since [by
> definition] everything is either at the same priority or importance
> levels and no decisions can be made [likely result in "No donor found"
> or "No Net Value"]
>
> If I read your comment correctly, you're referring to only one specific
> instance where circumstances conspire to cap the CPU resource [which
> has nothing to do with your WLM policy]. In that situation your
> objective is simply to keep the workload below utilization thresholds
> so that peaks can exceed the cap and gain the extra CPU resources.
> It's not a question of micromanagement then, it's simply a matter of
> not running work if you know that heavier loads are coming that need to
> exceed the soft-cap.
>
> Adam
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
