This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Unified tracing buffer
- From: "Martin Bligh" <mbligh at google dot com>
- To: "Masami Hiramatsu" <mhiramat at redhat 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 16:16:41 -0700
- Subject: Re: Unified tracing buffer
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1222125405; bh=bKXbvzfduK2SD2VsPeSyiKEGPTE=; h=DomainKey-Signature:Message-ID:Date:From:To:Subject:Cc: In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-Disposition:References:X-GMailtapped-By; b=TvUrh78wUWUmL8L u1eSCznFrK/gCElXk78dsgtL8ssbGkZtlZBx2sH7uNMEFQjB+OnYRcilz3NEFg9MRo4 wcug==
- Domainkey-signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references:x-gmailtapped-by; b=RtquDuxdtfXi4BdgWTy+E+t3WW1sgtuXBXcXP0kseGyPdWLhi/17mgUCewOGgFVLc ceUyJDA5vS64bA0TYFOqg==
- References: <33307c790809191433w246c0283l55a57c196664ce77@mail.gmail.com> <48D7F5E8.3000705@redhat.com> <33307c790809221313s3532d851g7239c212bc72fe71@mail.gmail.com> <48D81B5F.2030702@redhat.com>
>> 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.