Hi Aubrey, Li, Aubrey wrote: > I't s a bit hard for me to understand why we need to implement p-state > policy or c-state policy in PAD. IMHO, what PAD does is how to choose > CPU, according to the domain power state. All the cores in the P-state > domain are assumed to run at the same speed. All the cores in the > C-state > domain are assumed to sleep at the same deep level. PAD just needs to > collect these information and determines which domain, which CPU should > be choosed for the next thread scheduled. >
Yes, the dispatcher awareness of the states is certainly key here, so far the discussions in this thread have been mainly around the prototyped event driven P-state management. You are right in that we could simply implement the P-state policy in a driver, and implement the dispatcher awareness of those states...but the idea is to also leverage the dispatcher's knowledge of CPU utilization to do this in an event driven fashion, rather than the polling one that we have today. We would really like to get away from polling. > When P-state does the speed transition should be put into P-state > driver. > And a x-call is needed or not may not have big impact to PAD. P-state > speed > transition still needs to be checked periodically corresponding to the > workload. > > C-state has the samiliar methodology, the next idle type will not be > decided > by PAD, still decided by the time of last c-state residency. And > according to > the policy and current c-state domain power state, PAD decides whether > to > schedule the next thread to the C3 domain or C0 domain. > I agree. Note that the dispatcher isn't making these sorts of power management policy decisions, but is instead tracking the domain utilization as it does it's job scheduling threads.. It's up to the CPU power manager to decide when to make these state changes given that utilization. The dispatcher is just helping provide better data, while considering the power states as it schedules threads. -Eric
