On 10/22/08 10:01, Eric Saxe wrote: > Hi Aubrey, > > Li, Aubrey wrote: > >> Currently we have two kinds of cmt policy across the hierarchical processor >> group. So it's possible a thread want to be dispatched by the performance >> policy but there is only power related processor group avaiable. >> >> The following patch adds a member into kthread_t structure, and use the same >> event driver which is used to notify cpupm to change p-state, to make the >> next >> kernel thread sensitive to the cmt policy, so that in later cmt balance, we >> can choose cpu by searching the related target processor group, unrelated >> groups will be ignored. >> >> What do you think? >> > > It makes sense to me to consider only certain levels of the PG hierarchy > for load balancing and coalescence depending on things like resource > utilization, policy preferences, etc. I wasn't thinking that this would >
For example a fully loaded system could ignore the Idle Power PG level. > be implemented on a per thread basis however. At least for now, I was > thinking this would be implemented on a per CPU basis, by modifying the > lineage in the CPU's PG data when the policy is changed (for example, > removing the power domain from from the lineage for performance mode (or > at least demoting it below the load balancing one)). That way, we don't > Since the PG lineage is per-cpu, we could create a non-homogeneous policy system. For example a moderately loaded 2-socket system could schedule most threads onto one socket which has performance lineage while the other socket has just power saving lineage. > have have to add the extra conditional logic in cmt_policy.c...which is > somewhat performance critical. > > Looking ahead, I can see the value of the per thread policy, but I don't > know if we have the motivation for it yet? > Per-thread settings would allow Real Time threads and high priority tasks to be scheduled by a different policy such as a more performance-oriented policy. Regards, Bill > Thanks, > -Eric > _______________________________________________ > tesla-dev mailing list > tesla-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/tesla-dev >
