Re: [PATCH 2/2 updated] Measure transition latency at driver initialization

["Ville Syrjälä" <syrjala@sci.fi>]

On Thu, Dec 01, 2005 at 10:05:31PM +0100, Eric Piel wrote:
> 01.12.2005 20:31, Mattia Dongili wrote/a écrit:
> >ok, updated patch attached (with a shiny diffstat!!). Looks a lot
> >nicer now :)
> >
> >Oh, what do you think of the request to report out-of-range frequencies
> >and set CPUFREQ_ETERNAL instead of setting an arbitrary high value? If
> >ok, shall I use my email address instead of the list's?
> >
> I was about to say this is fairly reasonable... until I tried it on my 
> laptop and notice that _I_ got this message :-( Transition measured: 
> 4500 nSec. It's probably because the clock source on my laptop is the 
> TSC, which on this old processor stops during transition. Therefore, 
> after being in the shoe of the poor user still not having the ondemand 
> governor working, I'd tend to prefer if the fallback transition latency 
> could be a high and safe, but still usable, value. Anyway, we _know_ 
> that those processors are not so slugish to do transition that it should 
> be considered "eternal" :-)
> 
> So what about putting it to 500 uSec, knowing that on my 1GHz PIII it 
> took something like 200uSec, it should be safe everywhere:

I'm going to jump in here with some measurements I got with 
do_gettimeofday().

speedstep-ich on my 933 MHz Tualatin seems to agree with the 200 usec 
figure.

speedstep-smi takes ~1670 usec on my 700 MHz Coppermine. That is when it 
succeeds to change the frequency on the first try. That fails quite 
often and with one retry the time goes up to ~72 msec (thanks to the 
mdelay() in the loop). It will try to change the frequency six times 
before giving up and at that point it may have wasted over one second. 
Isn't that a "bit" too long to spend with irqs disabled?

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/