lkml.org 
[lkml]   [2008]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 1/3] Unified trace buffer


On Wed, 24 Sep 2008, Martin Bligh wrote:
>
> If we use 32 bits instead of 27, then the timestamp events are only
> about once per second, which is probably fine for overhead ... ?

You'd have them ONCE IN A BLUE MOON.

If there is nothing going on, you don't need the timestamps at all.

Yes, some people will _want_ a heartbeat, of course, and there might be
serialization points where we want to serialize some external clock to the
TSC, but that's a separate issue from generating a full TSC value. We may
well decide that once a second we want a whole packet with TSC _and_
HR-timer sync information, for example. But that's a separate issue.

And if there is a lot of things going on (eg you're tracing things like a
block device performance issue), you have events _much_ closer to each
other than 1/30th of a second, and you again _never_ need a full 59-bit
timestamp. Because the delta would be cumulative, and as long as you are
generating events, you're also updating the base TSC.

The only case you'll see lots of those timestamps (where "lots" is
guaranteed to be less than 30 in one second) would be if you're tracing
something that literally does a couple of events per second. But then you
sure as hell don't need to worry about performance _or_ memory use. If you
have some trace that gives you five hits per second (and spread out, to
boot!), you'll generate twice the number of trace entries because each
entry would always be preceded by an extended thing, but hey, do we really
worry about five trace events per second?

And quite frankly, most of the tracing I've ever done really does fall
into the "either nothing" or "a flood of events" thing. The "5-25 events
per second at regular intervals" case really doesn't sound very common at
all - not that I would worry about it if it was since it's going to be a
really simple case..

And btw, this would be an issue only on really fast CPU's anyway. If
you're in the mobile space, your TSC will be clocking at less than that,
so the slower the machine, the less the overhead. Again, that's exactly
what you want - the overhead is not some fixed thing that is detemined by
the fastest possible TSC and hurts slower machines too, it's relative to
the speed of the machine itself.

(Of course, with cpufreq and fixed TSC's, a 2GHz CPU will have a 2GHz TSC
even when it's running at just 1GHz, but the worry is more about trying to
trace on an embedded board with some pitiful 500MHz thing that is pretty
overworked anyway).

Linus


\
 
 \ /
  Last update: 2008-09-24 22:43    [W:0.543 / U:0.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site