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 > > >WLM bases its management on current resources and workload. It has no > >way of "knowing" that giving available resources to lower priority > work > >now when resources may be plentiful may result in raising the rolling > >4-hour MSU average to the point that in the future the LPAR may become > >capped at a time of peak load of high priority workload, denying that > >later high-priority workload the ability to use any CP resources above > >the MSU cap to handle short-term peaks. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
