http://defect.opensolaris.org/bz/show_bug.cgi?id=4015
--- Comment #12 from Eric Saxe <eric.saxe at sun.com> 2008-10-27 13:54:30 ---
Hi Aubrey,
> * 5. if nsiblings = 1, ipipe group will be ignored.
> */
>
> ----snip-----
> } while (++level < GROUP_SIZE(cmt_pgs));
>
> That is not what cmt dispatcher expected, is it?
It is. There's two PGs that exist at the core / pipeline level:
----CACHE-----
/ | | \
IDLE IDLE IDLE IDLE
| | | |
IPIPE IPIPE IPIPE IPIPE
/ \ / \ / \ / \
0 1 2 3 4 5 6 7
In this case, both the IDLE and IPIPE groups have identical groups of CPUs...at
the core level. Across the siblings the IDLE level, coalescence is done, and
across the siblings at the IPIPE level, load balancing is done. The siblings
set is defined to be the group of PGs who share the same parent (comment #10
says why it was done this way). Note that with the above hierarchy
configuration, the coalescence policy will be implemented, but load balancing
will not. Because the PGs at the load balancing level (IPIPE) have no siblings.
If the configuration looked like this:
-----CACHE------
/ | | \
IPIPE IPIPE IPIPE IPIPE
| | | |
IDLE IDLE IDLE IDLE
/ \ / \ / \ / \
0 1 2 3 4 5 6 7
...load balancing would be implemented at the core level, and coalescence would
not...because the PGs at the IDLE level have no siblings. So this is by design.
By promoting the level with the desired policy (in this diagram, either IDLE or
IPIPE), one can select which policy should be employed.
Hope this makes sense?
--
Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.