Hi Eric, Eric.Saxe 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. What event will drive p-state transition? The current one in PAD will cause high CPU utilization even if the system is idle. As far as I know, the two known methods are related to polling. 1) The hardware feedback mechanism provided by APERF/MPERF. 2) The software mechanism if idle time is larger than the current threshold in a time window. What's problem with periodically checking? Currently, if we set the the cpu threshold to 1 second, it may be far away from per second checking. But I think 1 second polling should be okay after Mark put his related change back to the kernel to make 1 second polling on time. Thanks, -Aubrey
