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-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
