Thread (25 messages) flat view 25 messages, 5 authors, 2015-02-02

Re: [PATCH v4 3/3] perf: Sample additional clock value

From: John Stultz <hidden>
Date: 2015-01-05 19:17:42
Also in: lkml

On Mon, Jan 5, 2015 at 5:45 AM, Peter Zijlstra [off-list ref] wrote:
On Thu, Nov 06, 2014 at 04:51:58PM +0000, Pawel Moll wrote:
quoted
Currently three clocks are implemented: CLOCK_REALITME = 0,
CLOCK_MONOTONIC = 1 and CLOCK_MONOTONIC_RAW = 2. The clock field is
5 bits wide to allow for future extension to custom, non-POSIX clock
sources(MAX_CLOCK for those is 16, see include/uapi/linux/time.h) like
ARM CoreSight (hardware trace) timestamp generator.
quoted
@@ -304,7 +305,16 @@ struct perf_event_attr {
                              mmap2          :  1, /* include mmap with inode data     */
                              comm_exec      :  1, /* flag comm events that are due to an exec */
                              uevents        :  1, /* allow uevents into the buffer */
-                             __reserved_1   : 38;
+
+                             /*
+                              * clock: one of the POSIX clock IDs:
+                              *
+                              * 0 - CLOCK_REALTIME
+                              * 1 - CLOCK_MONOTONIC
+                              * 4 - CLOCK_MONOTONIC_RAW
+                              */
+                             clock          :  5, /* clock type */
+                             __reserved_1   : 33;

      union {
              __u32           wakeup_events;    /* wakeup every n events */
This would put a constraint on actually changing MAX_CLOCKS, are the
time people OK with that? Thomas, John?
Yea, I'd not want to enshrine MAX_CLOCKS if we can avoid it. We're
getting a bit close to it these days.

thanks
-john
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help