lkml.org 
[lkml]   [2008]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2008-09-26 00:59    [W:0.163 / U:0.640 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site