Liu, Jiang wrote:
> 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.
>
Thanks. The code as it's currently written lends itself particularly
well to "Software any". Mark, Anup, Bill and I were discussing a few
days ago ideas for what the implementation of the current simply policy
would look like under modes 1 or 3.
What's currently implemented is analogous to how a one might manage the
state of a light switch in a room.
- First one in the room turns the switch on.
- Last one out of the room turns the switch off.
- No polling to see if someone left the room without turning the switch off.
This policy makes sense if P-state transitions are inexpensive. The more
x-calls are needed to implement P-state transitions, the higher the
transition cost (at least from the software point of view). Mark was
remarking that even if the hardware handles the coordination, that it
might still be expensive because it simply means someone else (the
hardware) is having to do more work.
We want to be able to leverage any coordination the hardware is able to
do, since that can reduce the number of xcalls needed to have a domain
transition P-states. The best case for this is mode 2, where zero
x-calls are needed, and the worst seems to be mode 1, where you always
need to x-call all CPUs to have the domain transition P-states. Mode 3
is somewhere in the middle. If we can assume the behavior in 3 (that for
example, the real P-state for the domain is the fastest P-state
requested), then that will help us to better understand when xcalls are
needed, and when they aren't.
The other way to go here, is to always have CPUs make their own P-state
transitions, and then track in software the actual speed of the domain.
This has the benefit of never requiring x-calls, but all CPUs would need
to request P-state transitions....which I suppose, if necessary is
better than having to do it via a x-call.
I think it's important that we:
- have an understanding of the real "performance" state of the
domain, since that will influence where threads are scheduled to run.
- don't have to poll to determine when state transitions should happen
- find a good balance between the overhead resulting from policy
evaluation and state transitions, and being responsive about making
those state transitions.
Depending on the overhead, we can add some hysteresis into the
policy...for example by only requesting a raising of P-state when a
thread has successfully finished it's time quantum, or is switching to
another (non-idle) thread...which would help eliminate state transitions
thrashings triggered by otherwise transient system activity.
Thoughts?
Thanks,
-Eric
