Messages in this thread | | | Date | Fri, 27 Mar 2015 09:52:25 -0700 | Subject | Re: [tip:perf/timer] perf: Add per event clockid support | From | Stephane Eranian <> |
| |
On Fri, Mar 27, 2015 at 9:35 AM, Peter Zijlstra <peterz@infradead.org> wrote: > On Fri, Mar 27, 2015 at 09:31:45AM -0700, Stephane Eranian wrote: >> On Fri, Mar 27, 2015 at 4:48 AM, tip-bot for Peter Zijlstra >> > +static int perf_event_set_clock(struct perf_event *event, clockid_t clk_id) >> > +{ >> > + bool nmi_safe = false; >> > + >> > + switch (clk_id) { >> > + case CLOCK_MONOTONIC: >> > + event->clock = &ktime_get_mono_fast_ns; >> > + nmi_safe = true; >> > + break; >> > + >> > + case CLOCK_MONOTONIC_RAW: >> > + event->clock = &ktime_get_raw_fast_ns; >> > + nmi_safe = true; >> > + break; >> > + >> > + case CLOCK_REALTIME: >> > + event->clock = &ktime_get_real_ns; >> > + break; >> > + >> > + case CLOCK_BOOTTIME: >> > + event->clock = &ktime_get_boot_ns; >> > + break; >> > + >> > + case CLOCK_TAI: >> > + event->clock = &ktime_get_tai_ns; >> > + break; >> > + >> Can all those clocks be safely called from an NMI context? > > + if (!nmi_safe && !(event->pmu->capabilities & PERF_PMU_CAP_NO_NMI)) > + return -EINVAL; > > no :-)
Ok, I see. But on architectures which do not have NMI, they would all be safe. And that would work if they set the PERF_PMU_CAP_NO_NMI flag on their pmu->capabilities.
Next, I am trying to understand how perf is going to expose this. I am thinking about this in the context of my jitted code patches. With this approach, the jit runtime and the perf tool need to agree on the clock they are using. That mean they need to advertise or document the clock they use and there needs to be an option in perf record to pass that same clockid.
In my current patch series, using Pawel's clock patch, the kernel advertises in procfs the clockid used (all events use the same). The jit runtime simply reads the id and uses it to timestamp jit events.
| |