Messages in this thread | | | Date | Fri, 26 Sep 2008 00:55:58 +0200 | From | Ingo Molnar <> | Subject | Re: [RFC PATCH 1/3] Unified trace buffer |
| |
* Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> Linus Torvalds wrote:
> > The reason I say "and no" is that it's not technically really > > possible to atomically give the exact TSC at which the frequency > > change took place. We just don't have the information, and I doubt > > we will ever have it. > > Well, you don't need the tsc at the precise moment of the frequency > change. You just need to emit the current tsc+frequency+wallclock > time before you emit any more delta records after the frequency > change. You can't fetch all those values instantaneously, but you can > get close.
hm, i'm not sure you've thought through this delta record idea.
Take a system that goes idle thousands of times a second. (it's easy - just some networking workload)
Now take a tracer that just wants to emit a trace entry every now and then. Once or twice a second or so.
Note that suddenly you have thousands of totally artificial 'delta' time records between two real events, and have to post-process all your way up between these events to get to the real timeline.
... it is totally impractical and costly.
and then i havent even mentioned some other big complications:
- the numeric errors that mount up over thousands of delta events
- the memory overhead over thousands of entries
- the fact that cpufreq and PLL changes are rarely atomic and that the TSC can flip-flop between two frequencies.
TSC based delta time post-processing is just not practical. Micro-time has to be synced up to GTOD in some manner - OR you might declare that the TSC _has_ to never stop and has to be constant. (no modern x86 CPU meets that criterium at the moment though.)
... and the moment you accept the fact that the GTOD _has_ to be mixed into it, all the rest follows pretty much automatically: either you store the (GTOD,freq,TSC) triple and post-process that absolute timestamp, and you accept the in-memory cost of that and do post-processing, or you compress that triple in situ and store the result only.
[ You will then also want some fall-back implementation for CPUs that have no TSCs, and for architectures that have no default implementation - something jiffies based. And you want some special hooks for paravirt, as always. ]
I.e. you will end up having something quite close to cpu_clock()/sched_clock().
_Or_ if you manage to get any better than that for tracing then please tell us about it because we want to apply those concepts to cpu_clock()/sched_clock() too :-)
Ingo
| |