Eric.Saxe wrote: > Hi Aubrey, > > Li, Aubrey wrote: >> The policy seems not to be good. >> It prevents the core from going into idle. When the new kthread is >> idle thread, the policy will change the power state to low power >> state, this calls speedstep power interface on IA platform, which is >> implemented by xcall. the core may spend some time to grab highest >> mutex here. >> > I'd like to see this done in a way that doesn't require the > xcall. Is it > possible to do the P-State transition such that one CPU (the current > CPU), affects the whole P-state domain, eliminating the need > for the xcall? > We can't eliminate xcall as long as P-state driver is under solaris pm framework. You know, p-state transition is dispatched by the taskq, which could run on any processor.
>> P-state policy implemented in cmt thread switch here seems not to be >> a good idea. > Are you saying this because a xcall would be needed? > >> We can't upgrade or downgrade the speed level just by the old >> thread or >> the new thread is idle thread. > That's the implementation of the current (rather naive) policy. It's > really about utilization of the P-state domain, and currently that > utilization is tracked by looking at transitions between idle and > non-idle threads. > I mean the transition determined by looking at idle and non-idle threads. The next thread(idle thread or not) is changed frequently, specially the current implementation put this policy in swtch(), this may cause p-state transition occur quite frequently, kernel spends much time doing this even the actual system workload is very light, so that the CPU utilization is very high even the system is idle. >> We probably still need change it >> according to the >> system workload. >> > Why not on a (P-state) domain by domain basis? We're trying to > made some > headway towards optimizing for larger systems that are only partially > utilized....which is difficult to do considering the system > wide workload... > I think we need to do the p-state transition according to the workload, it could be a domain workload or a system wide workload, we can't make a transition by the policy discussed above. I guess we are talking about the same thought here, :-) Thanks, -Aubrey
