Probably the high CPs share cache. Going to a middle or low CP probably would required invalidating some cache and loading cache on the new CP. Would be slower than waiting for the CP in a few cycles. With the MSU capping, it can run more CPs slower, and the waits don't count toward usage.
On Thu, Sep 29, 2016 at 11:43 AM, Peter Hunkeler <[email protected]> wrote: >>>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 tasks in parallel "at the >>same point in time" than there are Logical CPs available, which can't be more >>than the number of physical CPs available at that instant. > > > > > Sorry for not being clear enough. > > > I understand that with HiperDispatch on, WLM creates "CP nodes" based on the > topology. The LPAR in question has 12 LCPs, 4 highs, 1 medium and 7 lows. > This would lead to 2 nodes with 2 highs each, the medium in one of the nodes > and the lows spread (3 & 4?). > > > WLM then creates a work unit queue (WUQ, or dispatcher queue) for each node. > Work units (WU) are then assigned to a node, so only CPs from that node will > select WUs from that node. I'm assuming that the assignement to a node is an > address space attribute and not a WU atttibute (would neglect the positice > effect processor caches for which HiperDispatch was invented). > > > If all tasks of an address space are in the same node, there can never be > more WU running in parallel than there are (L)CPs in the node. In my example, > 2 highs plus the medium (for one node), up to 4 unparked (if unparked) low > CPs. That would explain why RMF sees often CP delay even though there is > plenty of spare capacity. > > > If all this is true, would givint the job higher "prioritiy" really help? > > > > > Caution: This is the first time I care to look into this in that depth. Maybe > I'm all wrong. Happy to learn the truth. > > > -- > Peter Hunkeler > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
