This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Unified tracing buffer
- From: Masami Hiramatsu <mhiramat at redhat dot com>
- To: Martin Bligh <mbligh at google dot com>
- Cc: 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 18:25:35 -0400
- Subject: Re: Unified tracing buffer
- References: <33307c790809191433w246c0283l55a57c196664ce77@mail.gmail.com> <48D7F5E8.3000705@redhat.com> <33307c790809221313s3532d851g7239c212bc72fe71@mail.gmail.com>
Hi Martin,
Martin Bligh wrote:
>> I agree to integrate tracing buffer mechanism, but I don't think
>> your proposal is the simplest one.
>>
>> To simplify, I think the layered buffering mechanism is desirable.
>> - The lowest layer just provides named circular buffers(both per-cpu and
>> uni-buffer in system) and read/write scheme.
>> - Next layer provides user/kernel interface including controls.
>> - Top layer defines packet(and event) formatting utilities.
>> - Additionally, it would better provide some library routines(timestamp,
>> event-id synchronize, and so on).
>>
>> Since this unified buffer is used from different kind of tracers/loggers,
>> I don't think all of them(and future tracers) want to be tied down by
>> "event-id"+"parameter" format.
>> So, Sorry, I disagree about that the tracing buffer defines its *data format*,
>> it's just overkill for me.
>
> I think you're right that we can layer this, and we didn't make a particularly
> good job of splitting those things out. I'll try to pull together
> another revision
> to reflect this and other suggested changes.
I'm happy to hear that. :-)
> 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.
By the way, systemtap uses two modes;
- single-channel mode
In this mode, all cpus share one buffer channel to write and read.
each writer locks spinlock and write a probe-local data to buffer.
- per-cpu buffer mode
In this mode, we use an atomic sequential number for ordering data. If
user doesn't need it(because they have their own timestamps), they can
choose not to use that seq-number.
Thank you,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com