From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7078 invoked by alias); 23 Sep 2008 00:07:21 -0000 Received: (qmail 6824 invoked by uid 22791); 23 Sep 2008 00:07:21 -0000 X-Spam-Status: No, hits=-0.5 required=5.0 tests=AWL,BAYES_40,J_CHICKENPOX_63,KAM_MX,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 23 Sep 2008 00:06:46 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m8N06jwZ008617 for ; Mon, 22 Sep 2008 20:06:45 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [10.16.255.12]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m8N06i9w032385; Mon, 22 Sep 2008 20:06:44 -0400 Received: from [10.16.3.219] (dhcp-100-3-219.bos.redhat.com [10.16.3.219]) by mail.boston.redhat.com (8.13.1/8.13.1) with ESMTP id m8N06huH005855; Mon, 22 Sep 2008 20:06:43 -0400 Message-ID: <48D832B6.3010409@redhat.com> Date: Tue, 23 Sep 2008 00:07:00 -0000 From: Masami Hiramatsu User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Martin Bligh CC: Linux Kernel Mailing List , Linus Torvalds , Thomas Gleixner , Mathieu Desnoyers , Steven Rostedt , darren@dvhart.com, "Frank Ch. Eigler" , systemtap-ml Subject: Re: Unified tracing buffer References: <33307c790809191433w246c0283l55a57c196664ce77@mail.gmail.com> <48D7F5E8.3000705@redhat.com> <33307c790809221313s3532d851g7239c212bc72fe71@mail.gmail.com> <48D81B5F.2030702@redhat.com> <33307c790809221616h5e7410f5gc37c262d83722111@mail.gmail.com> In-Reply-To: <33307c790809221616h5e7410f5gc37c262d83722111@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2008-q3/txt/msg00737.txt.bz2 Hi Martin, Martin Bligh 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. > > An atomic sequential number is: > > (a) far less meaningful than a timestamp for the user > (b) more expensive to compute in many cases. Sure, atomic counter might be more expensive but accurate for ordering. (and it can use on almost all architectures) The cost depends on the architecture and system configuration. So, I think it is preferable user to choose their timestamp rather than fix it. For example, calling callback when writing a log entry as following; write_log(struct buffer *buffer, char *data, int len) { /* reserve a logging space */ char *buf = reserve(buffer, len + buffer->timestamp.len); /* write a timestamp */ buf = buffer->timestamp.write(buf); /* write a body */ memcpy(buf, data, len); } And unified buffer prepares default timestamp.write callbacks. char * timestamp_write(char * buf); // write arch-specific timestamp char * seqnum_write(char * buf); // write an sequence number What would you think about it? > 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. Sure, that will work. > 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. For example, my laptop (this machine/Core2Duo) doesn't return correct TSC. :-( Thank you, -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division e-mail: mhiramat@redhat.com