Messages in this thread | | | Date | Wed, 24 Sep 2008 13:39:54 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [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
| |