Peter,
also within the same processor class (here CP) affinity nodes may help each
other - see the IEAOPTxx CCCAWMT parameter. Therefore, the number of (unparked)
logicals processors on a given affinity node does not necessarily limit the
number of concurrently disptached work units of an
Something to be aware of when looking at CPU delays being reported by
RMFIII, is that in multi-tasked asids, if ANY of the subtasks is found to
be in CPU wait when RMFII does it sampling sweep (once per second), then
that sampled second will have a 'CPU wait' associated with it, applying to
that
>You have to dig into queuing theory, arrival rate, arrival pattern, and
service duration of the work to understand why RMF is reporting CPU
delay samples yet WLM does not unpark processors to run it.
I think I have an idea of this even without knowing the theories.
>HiperDispatch is a
>>Is so, the job would not be able to run more CPs in parallel at any point in
>>time than there are LCPs in the node (highds, mediums, and unparked lows),
>>right?
>I am confused by this question. Of course, regardless of the other conditions
>that you've asked about, a job can never run more
On 9/29/2016 10:17 AM, Peter Hunkeler wrote:
So there should be enough spare capacity for the system (LPAR) to to use. But
it does not. The 7 vertical low CPs are mostly parked or unparked for only a
few percent. I wonder why MVS is not using more CPs and more Capacity for that
job.
You
>Cheryl's tuning letter fall 2015 described a case where they
implemented MSU capping ... [snip]
Ooops, I just saw the some text vanished from my mail... sorry for the
incpmpleted data..
I wanted to add that the CPU Activity Report shows the system (LPAR) being busy
between ~30% and ~50%
>For more on these issues, you can see our presentations from the last SHARE on
>our website at http://watsonwalker.com/publications/presentations/. And if
>you're a Tuning Letter subscriber, look at our 2015 No 4 issue for both the
>article that Mike mentioned and another article on how
