Message-ID: <54EAE11B.90303@intel.com>
Date: Mon, 23 Feb 2015 10:13:15 +0200
From: Adrian Hunter <adrian.hunter@intel.com>
Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki,
 Business Identity Code: 0357606 - 4, Domiciled in Helsinki 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Peter Zijlstra <peterz@infradead.org>
CC: pawel.moll@arm.com, john.stultz@linaro.org, mingo@kernel.org,
        eranian@google.com, linux-kernel@vger.kernel.org, acme@kernel.org,
        dsahern@gmail.com, fweisbec@gmail.com, jolsa@redhat.com,
        namhyung@gmail.com, paulus@samba.org, tglx@linutronix.de,
        rostedt@goodmis.org, sonnyrao@chromium.org, ak@linux.intel.com,
        vincent.weaver@maine.edu
Subject: Re: [RFC][PATCH 2/2] perf: Add per event clockid support
References: <20150220142930.013968488@infradead.org> <20150220143754.852733868@infradead.org>
In-Reply-To: <20150220143754.852733868@infradead.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1904
Lines: 47

On 20/02/15 16:29, Peter Zijlstra wrote:
> While thinking on the whole clock discussion it occured to me we have
> two distinct uses of time:
> 
>  1) the tracking of event/ctx/cgroup enabled/running/stopped times
>     which includes the self-monitoring support in struct
>     perf_event_mmap_page.
> 
>  2) the actual timestamps visible in the data records.
> 
> And we've been conflating them.
> 
> The first is all about tracking time deltas, nobody should really care
> in what time base that happens, its all relative information, as long
> as its internally consistent it works.
> 
> The second however is what people are worried about when having to
> merge their data with external sources. And here we have the
> discussion on MONOTONIC vs MONOTONIC_RAW etc..
> 
> Where MONOTONIC is good for correlating between machines (static
> offset), MONOTNIC_RAW is required for correlating against a fixed rate
> hardware clock.
> 
> This means configurability; now 1) makes that hard because it needs to
> be internally consistent across groups of unrelated events; which is
> why we had to have a global perf_clock().
> 
> However, for 2) it doesn't really matter, perf itself doesn't care
> what it writes into the buffer.
> 
> The below patch makes the distinction between these two cases by
> adding perf_event_clock() which is used for the second case. It
> further makes this configurable on a per-event basis, but adds a few
> sanity checks such that we cannot combine events with different clocks
> in confusing ways.
> 
> And since we then have per-event configurability we might as well
> retain the 'legacy' behaviour as a default.

OK by me.

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