On 11/05/08 11:24, bugzilla-daemon at defect.opensolaris.org wrote: > http://defect.opensolaris.org/bz/show_bug.cgi?id=4343 > > > > > > --- Comment #8 from Eric Saxe <eric.saxe at sun.com> 2008-11-05 11:24:15 --- > (In reply to comment #7) > >> I'll have to make this more clear. >> >> This is the current order. >> >> hierarchy >> || >> || \\ >> || = = Active domain group (package level) >> || | | | | >> || T0 T1 T2 T3 >> || >> || \\ >> || = = Idle domain group (core level) >> || | | >> || core0(domain0) core1(domain1) >> || | | | | >> || T0 T1 T2 T3 >> >> Once package is chosen, dispatcher will choose one CPU from the active >> domain. >> And if the CPU is chosen, what cmt_balance() does is done. cmt_balance will >> not >> go to the core level to choose CPU again. >> > > Right, once we decide to balance against another grouping, cmt_balance() looks > for the first idle CPU it finds in the group. It could be smarter about how it > does that, continuing down the hierarchy until it finds the best group to > migrate to...all within the same invocation of cmt_balance(). > > Currently, the algorithm relies on the fact that it's called frequently (each > time through the dispatcher, so it's not a big deal only balancing one level > per invocation...since we'll be back around shortly). It was done this way to > minimize the latency of calling the routine (since this is a very hot code > path). But I agree that in this case the cost of making the suboptimal choice > of choosing to run on the CPU in the deep c-state (T2) before we detect that > we > should migrate over to the T1 is really costly in this case...so the extra > work > in cmt_balance() to get this right the first time might be justified. >
Is our long term goal to dynamically ignore Idle domain groups when system load is above a threshold? Bill >> If no target PG is found at package level, then core level will be searched. >> >> So, I think idle domain should be ahead of the active domain. >> Or I'm totally wrong. >> > > I think you're on to something here Aubrey. :) Let's pursue this as part of a > separate bug... > >
