[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <33307c790809221616h5e7410f5gc37c262d83722111@mail.gmail.com>
Date: Mon, 22 Sep 2008 16:16:41 -0700
From: "Martin Bligh" <mbligh@...gle.com>
To: "Masami Hiramatsu" <mhiramat@...hat.com>
Cc: "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
"Linus Torvalds" <torvalds@...ux-foundation.org>,
"Thomas Gleixner" <tglx@...utronix.de>,
"Mathieu Desnoyers" <compudj@...stal.dyndns.org>,
"Steven Rostedt" <rostedt@...dmis.org>, od@...ell.com,
"Frank Ch. Eigler" <fche@...hat.com>,
systemtap-ml <systemtap@...rces.redhat.com>
Subject: Re: Unified tracing buffer
>> 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.
An atomic sequential number is:
(a) far less meaningful than a timestamp for the user
(b) more expensive to compute in many cases.
I think we came up with a way to approximate this, using a callback every
ms or so as the higher order bits, and a sequential counter in the lower
order for those broken platforms.
But perhaps it would be better if we started with a discussion of which
platforms can't do global timestamps, and why not? I know some of them
are fixable, but perhaps not all.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists