Hi Aubrey, Li, Aubrey wrote: > What event will drive p-state transition? > I think that's a good policy question. The current code kicks the p-state domain to P0 when some non-idle thread begins to run on a CPU in the domain, and then goes back down to the slowest P-state when the last CPU in a formerly busy domain goes idle again. Like I was saying in my previous mail, those particular event triggers may cause too many state transitions (and therefore overhead) to be worthwhile. > The current one in PAD will cause > high CPU utilization even if the system is idle. > Why is that Aubrey?
> 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? As long as it's not done too often, there overhead won't be high (in terms of performance), but my concern is that as we start taking advantage of deeper c-states it could become more costly. Going down the road of eliminating polling in the system seems good because otherwise we would be undermining our tickless efforts. With polling, there's also a lag between the time the CPU utilization changes, and the time that we notice and change the power state. This means that at times were running a thread on a clocked down CPU, which is poor for performance....or the CPU is idle, but running flat out (which as Mark pointed out could be ok from a "race to C-state" perspective). If it's even driven, we can know precisely when utilization has changed...and so if the state transitions are cheap enough, why not just make them then? -Eric Thanks, -Eric
