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? > >> 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? It's dependent on the domain coordination method, currently there are three kinds of domain coordination: 1) Software all mode: to transit a domain into a specific P-state, software needs to write to P-state control register on every CPU in the domain. 2) Software any mode: to transit a domain into a specific P-state, software only needs to write to P-state control registre on one of the CPUs in the domain. 3) Hardware coordination mode: each CPU in the domain writes what it wants to P-state control register and hardware/BIOS will choose the correct P-state for the domain. so the answer to your question is it depends and a domain controller is needed to support different coordination methods.
> >> 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. > >> 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... > > Thanks, > -Eric > >> Thanks, >> -Aubrey >> >> > > _______________________________________________ > tesla-dev mailing list > tesla-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/tesla-dev
