Subject: Re: [PATCH 1/2] perf tools: Add reference timestamp to perf header
From: Peter Zijlstra <peterz@infradead.org>
To: "David S. Ahern" <daahern@cisco.com>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
        Frederic Weisbecker <fweisbec@gmail.com>,
        linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <4D065CB2.7050104@cisco.com>
References: <1291773285-16254-1-git-send-email-daahern@cisco.com>
	 <1291773285-16254-2-git-send-email-daahern@cisco.com>
	 <20101212201613.GA1784@nowhere> <4D06301C.2090309@cisco.com>
	 <20101213155451.GA1691@nowhere> <20101213164854.GL5407@ghostprotocols.net>
	 <20101213170923.GB1691@nowhere> <1292260289.6803.297.camel@twins>
	 <20101213171537.GC1691@nowhere> <1292260699.6803.305.camel@twins>
	 <20101213172216.GB7417@ghostprotocols.net>
	 <1292261716.6803.332.camel@twins> <1292262433.6803.351.camel@twins>
	 <4D065CB2.7050104@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Date: Mon, 13 Dec 2010 18:57:04 +0100
Message-ID: <1292263024.6803.370.camel@twins>
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1701
Lines: 37

On Mon, 2010-12-13 at 10:49 -0700, David S. Ahern wrote:
> 
> On 12/13/10 10:47, Peter Zijlstra wrote:
> > On Mon, 2010-12-13 at 18:35 +0100, Peter Zijlstra wrote:
> >>         * this CLOCK_MONOTONIC offset (for what little good that does, since
> >> our clock isn't strictly sync'ed to CLOCK_MONOTONIC so we can incur
> >> arbitrary drift). 
> > 
> > In fact, the only sane way to do that is by creating a software counter
> > that represents CLOCK_MONOTONIC and sample that say once a minute (or
> > more often if you want smaller drift).
> > 
> > 
> 
> What about creating a PERF_RECORD_TIME and generate an event when the
> counter is opened? It contains a PERF_SAMPLE_TIME and say
> PERF_SAMPLE_TOD (time-of-day)? We're not sending rockets to saturn; we
> just need the timestamps to match other log files.

That's similar to the first thing I proposed. The problem is with long
record sessions your drift can become quite significant, then when you
merge sort your other log events stuff can get out of order. Which can
lead to some serious head-scratching..

Another problem with this approach is things like flight-recorder mode
where you constantly over-write your old data, you'd have to build some
trigger to always output a new record before you over-write the old one,
so there's always one consistent record around. Drift is an even more
serious problem here since flight-record more could be running for days
before (if ever) you dump it.


--
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/