From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754672AbYIZB1x (ORCPT ); Thu, 25 Sep 2008 21:27:53 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754562AbYIZB1k (ORCPT ); Thu, 25 Sep 2008 21:27:40 -0400 Received: from gw.goop.org ([64.81.55.164]:56081 "EHLO mail.goop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752804AbYIZB1j (ORCPT ); Thu, 25 Sep 2008 21:27:39 -0400 Message-ID: <48DC3A89.9020407@goop.org> Date: Thu, 25 Sep 2008 18:27:37 -0700 From: Jeremy Fitzhardinge User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Steven Rostedt CC: Linus Torvalds , Ingo Molnar , Martin Bligh , Peter Zijlstra , Martin Bligh , linux-kernel@vger.kernel.org, Thomas Gleixner , Andrew Morton , prasad@linux.vnet.ibm.com, Mathieu Desnoyers , "Frank Ch. Eigler" , David Wilder , hch@lst.de, Tom Zanussi , Steven Rostedt Subject: Re: [RFC PATCH 1/3] Unified trace buffer References: <33307c790809241403w236f2242y18ba44982d962287@mail.gmail.com> <1222339303.16700.197.camel@lappy.programming.kicks-ass.net> <8f3aa8d60809250733q70561e6agfa3b00da83773e9f@mail.gmail.com> <1222354409.16700.215.camel@lappy.programming.kicks-ass.net> <33307c790809250825u567d3680w682899c111e10ed6@mail.gmail.com> <20080925153635.GA12840@elte.hu> <48DBFC7D.4050208@goop.org> <48DC1338.6050107@goop.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Steven Rostedt wrote: > How do you get this GTOD read in the ring buffer? If the ring buffer does > it without any knowledge from the tracer, it may be doing it a > inappropriate times. This would also imply that the GTOD infrastructure > itself is reentrent safe. Imagine tracing the GTOD code when the buffer > decides it is about time to add the GTOD timestamp into the buffer. Can > the GTOD handle this recursion. If the GTOD has spinlocks, probably not. > It doesn't need to read the GTOD synchronously when writing the trace record. When a tsc event occurs, it needs to store the GTOD/tsc/frequency somewhere at that point. When you next write a trace record, if that structure has been updated, you write it into the trace before emitting the next delta timestamp. In fact you can read the GTOD at almost any time between tsc frequency updates, so you can defer it to whenever is convenient. At the time the tsc changes frequency, you emit: (tsc,frequency), and a bit later (before it changes again) you emit (tsc,GTOD). That allows you to retroactively compute GTODs for all timestamps. Obviously it would be good to get them as close as possible together. J