From: Adrian Hunter <adrian.hunter@intel.com>
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
Date: Mon, 23 Feb 2015 10:13:15 +0200 [thread overview]
Message-ID: <54EAE11B.90303@intel.com> (raw)
In-Reply-To: <20150220143754.852733868@infradead.org>
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.
prev parent reply other threads:[~2015-02-23 8:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-20 14:29 [RFC][PATCH 0/2] On perf and clocks Peter Zijlstra
2015-02-20 14:29 ` [RFC][PATCH 1/2] time: Add ktime_get_mono_raw_fast_ns() Peter Zijlstra
2015-02-20 19:49 ` John Stultz
2015-02-20 20:11 ` Peter Zijlstra
2015-03-17 11:24 ` Peter Zijlstra
2015-03-18 19:48 ` John Stultz
2015-02-20 14:29 ` [RFC][PATCH 2/2] perf: Add per event clockid support Peter Zijlstra
2015-02-20 15:28 ` Pawel Moll
2015-02-20 16:01 ` Peter Zijlstra
2015-02-23 8:13 ` Adrian Hunter [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54EAE11B.90303@intel.com \
--to=adrian.hunter@intel.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=dsahern@gmail.com \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=john.stultz@linaro.org \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@gmail.com \
--cc=paulus@samba.org \
--cc=pawel.moll@arm.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sonnyrao@chromium.org \
--cc=tglx@linutronix.de \
--cc=vincent.weaver@maine.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.