Messages in this thread | | | Date | Fri, 11 Apr 2008 10:40:29 +0200 | From | Andi Kleen <> | Subject | Re: [PATCH] x86: set_cyc2ns_scale() remove tsc_now and ns_now |
| |
On Fri, Apr 11, 2008 at 10:25:09AM +0200, Guillaume Chazarain wrote: > On Fri, Apr 11, 2008 at 10:06 AM, Andi Kleen <andi@firstfloor.org> wrote: > > At some point you have to generate an offset to something and that > > offset must be different for different frequencies, otherwise > > you get large systematic errors > > This offset is already there, represented by rq->clock - sched_clock()
Same issue. Think about it. Perhaps I should have written the complicated proof :)
You really have to compute the offset before the scaling, otherwise it is useless.
TSC is a counter that adds up time units. Now when the frequency changes the time units change, but counter doesn't reset.
Now the full absolue value of the counter is useless for exact time because there is no way to reconstruct what the lengths of the different time units meshed together in the single counter value were and how long it ticked at the different frequencies.
So after a frequency change the only way to get anything approaching a sane time is to take a snapshot of the counter already ticking at the new frequency (but before it is scaled!) and then only work with current TSC - snapshot and only scale after that.
Then there is also the issue that you don't know when exactly the counter changes and any measurements during that time might be dodgy (but system is not usually fully stopped during it).
The rewritten sched_clock handled this by having a unstable period between cpufreq starting to change, cpufreq reporting end of change and falling back to another clock during this instable period.
Also there are of course other users, like printk who don't have rq->clock.
-Andi
| |