Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753267AbYJQH7S (ORCPT ); Fri, 17 Oct 2008 03:59:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751611AbYJQH7F (ORCPT ); Fri, 17 Oct 2008 03:59:05 -0400 Received: from viefep18-int.chello.at ([213.46.255.22]:43329 "EHLO viefep18-int.chello.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751152AbYJQH7D (ORCPT ); Fri, 17 Oct 2008 03:59:03 -0400 X-SourceIP: 213.46.9.244 Subject: Re: [RFC patch 00/15] Tracer Timestamping From: Peter Zijlstra To: Mathieu Desnoyers Cc: Linus Torvalds , Andrew Morton , Ingo Molnar , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Steven Rostedt , Thomas Gleixner , David Miller In-Reply-To: <20081016232729.699004293@polymtl.ca> References: <20081016232729.699004293@polymtl.ca> Content-Type: text/plain Date: Fri, 17 Oct 2008 09:59:13 +0200 Message-Id: <1224230353.28131.65.camel@twins> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2359 Lines: 50 On Thu, 2008-10-16 at 19:27 -0400, Mathieu Desnoyers wrote: > Hi, > > Starting with the bottom of my LTTng patchset > (git://git.kernel.org/pub/scm/linux/kernel/git/compudj/linux-2.6-lttng.git) > I post as RFC the timestamping infrastructure I have been using for a while in > the tracer. It integrates get_cycles() standardization following David Miller's > comments I did more recently. > > It also deals with 32 -> 64 bits timestamp counter extension with a RCU-style > algorithm, which is especially useful on MIPS and SuperH architectures. Have you looked at the existing 32->63 extention code in include/linux/cnt32_to_63.h and considered unifying it? > There is also a TSC synchronization test within this patchset to detect > unsynchronized TSCs. We already have such code, no? Does this code replace that one or just add a second test? > See comments in this specific patch to figure out the > difference between the current x86 tsc_sync.c and the one I propose in this > patch. Right so you don't unify, that's a missed opportunity, no? > It also provides an architecture-agnostic fallback in case there is no > timestamp counter available : basically, it's > (jiffies << 13) | atomically_incremented_counter (if there are more than 8192 > events per jiffy, time will still be monotonic, but will increment faster than > the actual system frequency). > > Comments are welcome. Note that this is only the beginning of the patchset. I > plan to submit the event ID allocation/portable event typing aimed at exporting > the data to userspace and buffering mechanism as soon as I integrate a core > version of the LTTV userspace tools to the kernel build tree. Other than that, I > currently have a tracer which fulfills most of the requirements expressed > earlier. I just fear that if I release only the kernel part without foolproof > binary-to-ascii trace decoder within the kernel, people might be a bit reluctant > to fetch a separate userspace package. It might be good to drop all the ltt naming and pick more generic names, esp. as ftrace could use a lot of this infrastructure as well. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/