This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Unified tracing buffer
- From: "Darren Hart" <darren at dvhart dot com>
- To: "Masami Hiramatsu" <mhiramat at redhat dot com>
- Cc: "Martin Bligh" <mbligh at google dot com>, "Linux Kernel Mailing List" <linux-kernel at vger dot kernel dot org>, "Linus Torvalds" <torvalds at linux-foundation dot org>, "Thomas Gleixner" <tglx at linutronix dot de>, "Mathieu Desnoyers" <compudj at krystal dot dyndns dot org>, "Steven Rostedt" <rostedt at goodmis dot org>, od at novell dot com, "Frank Ch. Eigler" <fche at redhat dot com>, systemtap-ml <systemtap at sources dot redhat dot com>
- Date: Mon, 22 Sep 2008 16:11:48 -0700
- Subject: Re: Unified tracing buffer
- References: <33307c790809191433w246c0283l55a57c196664ce77@mail.gmail.com> <48D7F5E8.3000705@redhat.com> <33307c790809221313s3532d851g7239c212bc72fe71@mail.gmail.com> <48D81B5F.2030702@redhat.com>
On Mon, Sep 22, 2008 at 3:25 PM, Masami Hiramatsu <mhiramat@redhat.com> wrote:
>> One thing that I think is still important is to have a unified timestamp
>> mechanism on everything, so we can co-ordinate different things back
>> together in userspace from different trace tools, so I intend to keep
>> that at a lower level, but I think you're right that the event id, etc can
>> move up into separate layers.
>
> I'm not so sure that the unified 'timestamp' must be required by all tracers.
> If you just need to merge and sort per-cpu data, you can use an atomic
> sequential number for it.
> IMHO, the unified 'timestamp' would better be an option, because some
> architectures can't support it. I think preparing timestamp-callback
> function will help us.
>
There have been several posts on the timestamp for the events. From a
real-time perspective, this timestamp will be a very important datapoint for
each event, and the more accurate/higher resolution the better. Some thoughts.
o pretty print resolution should definitely be nanosecond (IMHO)
o internal storage should be "whatever is fastest" with the transformation to
ns data stored in the trace header (as I believe Mathieu mentioned).
o for archs where the clock isn't synchronized across CPUs, perhaps for now it
would be adequate to record the per cpu timestamps in the trace header and
include the cpu id for each event as well. This is in keeping with the
previous suggestion to collect the most primitive data available without
doing any sort of transformation at trace time.
--
Darren Hart