Re: [RFC] perf: need to expose sched_clock to correlate user sampleswith kernel samples
From: Thomas Gleixner
Date: Mon Feb 18 2013 - 15:36:12 EST
On Tue, 5 Feb 2013, John Stultz wrote:
> On 02/05/2013 02:13 PM, Stephane Eranian wrote:
> > But if people are strongly opposed to the clock_gettime() approach, then
> > I can go with the ioctl() because the functionality is definitively needed
> > ASAP.
> I prefer the ioctl method, since its less likely to be re-purposed/misused.
Urgh. No! With a dedicated CLOCK_PERF we might have a decent chance to
put this into a vsyscall. With an ioctl not so much.
> Though I'd be most comfortable with finding some way for perf-timestamps to be
> CLOCK_MONOTONIC based (or maybe CLOCK_MONOTONIC_RAW if it would be easier),
> and just avoid all together adding another time domain that doesn't really
> have clear definition (other then "what perf uses").
What's wrong with that. We already have the infrastructure to create
dynamic time domains which can be completely disconnected from
Tracing/perf/instrumentation is a different domain and the main issue
there is performance. So going for a vsyscall enabled clock_gettime()
approach is definitely the best thing to do.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/