linux-kernel - Re: [RFC][PATCH 2/2] perf: Add per event clockid support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 23 Feb 2015 10:13:15 +0200
From:	Adrian Hunter <adrian.hunter@...el.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	pawel.moll@....com, john.stultz@...aro.org, mingo@...nel.org,
	eranian@...gle.com, linux-kernel@...r.kernel.org, acme@...nel.org,
	dsahern@...il.com, fweisbec@...il.com, jolsa@...hat.com,
	namhyung@...il.com, paulus@...ba.org, tglx@...utronix.de,
	rostedt@...dmis.org, sonnyrao@...omium.org, ak@...ux.intel.com,
	vincent.weaver@...ne.edu
Subject: Re: [RFC][PATCH 2/2] perf: Add per event clockid support

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/