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. > 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... -- 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.
