transition latency

transition latency

[Ryan Underwood]

What's the purpose of the transition_latency field with respect to the
cpufreq infrastructure?  Should I be setting this to:
* the time it takes for my set_cpu_state function to execute and return
* the latency between the call to set_cpu_state and the actual CPU speed
change
* the time it takes for the hardware to respond to MY request (inside
set_cpu_state function) to change speeds

Just a little confused.  Here the problem is that my set_cpu_state
function could take up to 35ms to execute, but the actual frequency
transition ( a component of that function) happens within 7ms.  10ms is
the ondemand/conservative governors' upper limit for transition latency,
so if I take the whole function into account, those governors reject my
driver.

-- 
Ryan Underwood, <nemesis@icequake.net>

Re: transition latency

[Dominik Brodowski]

On Thu, Sep 28, 2006 at 07:32:47PM -0500, Ryan Underwood wrote:
> 
> What's the purpose of the transition_latency field with respect to the
> cpufreq infrastructure?  Should I be setting this to:
> * the time it takes for my set_cpu_state function to execute and return
> * the latency between the call to set_cpu_state and the actual CPU speed
> change
> * the time it takes for the hardware to respond to MY request (inside
> set_cpu_state function) to change speeds
> 
> Just a little confused.  Here the problem is that my set_cpu_state
> function could take up to 35ms to execute, but the actual frequency
> transition ( a component of that function) happens within 7ms.  10ms is
> the ondemand/conservative governors' upper limit for transition latency,
> so if I take the whole function into account, those governors reject my
> driver.

My original intention was this:

<timer starts>
- "system freeze" / IRQs off / ... (if needed)
- actual setting of the new frequency
- "system unfreeze" / IRQs on
- waiting until it is safe to return, and until
  it would also be safe to set the frequency anew.
<timer ends>

Note that 3 and 4 might be ordered differently in "real life". Also I'm not
totally sure that this "latency" is really what we need for ondemand et al.
So if anyone has a better input on what "latency" should mean here, speak up
please.

Thanks,
	Dominik

Re: transition latency

[Len Brown]

On Sunday 01 October 2006 22:25, Dominik Brodowski wrote:
> On Thu, Sep 28, 2006 at 07:32:47PM -0500, Ryan Underwood wrote:
> > 
> > What's the purpose of the transition_latency field with respect to the
> > cpufreq infrastructure?  Should I be setting this to:
> > * the time it takes for my set_cpu_state function to execute and return
> > * the latency between the call to set_cpu_state and the actual CPU speed
> > change
> > * the time it takes for the hardware to respond to MY request (inside
> > set_cpu_state function) to change speeds
> > 
> > Just a little confused.  Here the problem is that my set_cpu_state
> > function could take up to 35ms to execute, but the actual frequency
> > transition ( a component of that function) happens within 7ms.  10ms is
> > the ondemand/conservative governors' upper limit for transition latency,
> > so if I take the whole function into account, those governors reject my
> > driver.
> 
> My original intention was this:
> 
> <timer starts>
> - "system freeze" / IRQs off / ... (if needed)
> - actual setting of the new frequency
> - "system unfreeze" / IRQs on
> - waiting until it is safe to return, and until
>   it would also be safe to set the frequency anew.
> <timer ends>
> 
> Note that 3 and 4 might be ordered differently in "real life". Also I'm not
> totally sure that this "latency" is really what we need for ondemand et al.
> So if anyone has a better input on what "latency" should mean here, speak up
> please.

Just for reference, the ACPI spec _PSS and _TSS define latency this way:
"Indicates the worst case latency in microseconds that the CPU
is unavailable during a transition from a (performance) state to this (performance) state".

ie. it is the maximum period that the processor might execute no instructions
when you make this transition.

Which appears to correspond roughly to this one:

> > * the time it takes for my set_cpu_state function to execute and return

On Intel processors, you can ask the hardware for a new state right away --
even if it is internally still ramping the voltage and speed from the previous request.

cheers,
-Len

ps. I think you mean 10us above, not 10ms

Re: transition latency

[Ryan Underwood]

On Mon, Oct 02, 2006 at 01:07:51AM -0400, Len Brown wrote:
> 
> Just for reference, the ACPI spec _PSS and _TSS define latency this way:
> "Indicates the worst case latency in microseconds that the CPU
> is unavailable during a transition from a (performance) state to this (performance) state".
> 
> ie. it is the maximum period that the processor might execute no instructions
> when you make this transition.
> 
> Which appears to correspond roughly to this one:
> 
> > > * the time it takes for my set_cpu_state function to execute and return

Is it possible for that function to be preempted?  If it is, the only
time the CPU is truly unavailable is while it is in SMM.

> On Intel processors, you can ask the hardware for a new state right away --
> even if it is internally still ramping the voltage and speed from the previous request.

Right, same here.  Except in my case it's not ramping anything, it is
either changing FSB, multiplier, or enabling chipset throttling.

> cheers,
> -Len
> 
> ps. I think you mean 10us above, not 10ms

No, it's ms.  A single SMM round trip on one Toshiba laptop I have takes
~7ms (about 800K cycles on a 120MHz processor).  When I take into
account the SMM calls to set the cache, fan and friends, set_cpu_state
takes around 35ms.  If I set transition_latency to 7ms, ondemand and
conservative still work, but if I set it to 35ms (the true latency of
the set_cpu_state function), those governors are rejected because of
their TRANSITION_LATENCY_LIMIT.

So I'm still confused whether I should set transition_latency to the
latency of the individual SMM call (since the CPU will be available in
between calls), or the total execution time of set_cpu_state, or
something else.  It doesn't seem to hurt anything to set it to 7ms, but
there must be a reason for ondemand and conservative to have a limit on
it...

-- 
Ryan Underwood, <nemesis@icequake.net>