Messages in this thread | | | Date | Wed, 3 Apr 2013 16:00:05 +0200 | Subject | Re: [RFC] perf: need to expose sched_clock to correlate user samples with kernel samples | From | Stephane Eranian <> |
| |
On Wed, Apr 3, 2013 at 3:55 PM, David Ahern <dsahern@gmail.com> wrote: > On 4/3/13 3:17 AM, Stephane Eranian wrote: >> >> I haven't done any specific testing with either approach yet. The goal is >> to >> use this perf timestamp to correlate user level events to hardware >> events recorded >> by the kernel. I would assume there would be situations where those user >> events >> could be on the critical path, and thus the timestamp operation would have >> to be >> as efficient as possible. The vdso approach would be ideal. >> >>> >>> The performance/speed depends on how often is called. I have no idea what >>> Stephane's use case is but for me it is to correlate perf_clock >>> timestamps >>> to timeofday. In my perf-based daemon that tracks process schedulings, I >>> update the correlation every 5-10 minutes. >>> >> I was more thinking along the lines of runtime environments like Java >> where >> a JIT compiler is invoked frequently and you need to correlate samples in >> the >> native code with Java source. For that, the JIT compiler has to emit >> mapping >> tables which have to be timestamped as address ranges may be re-used. > > > What's the advantage of changing apps -- like the JIT compiler -- to emit > perf based timestamps versus having perf emit existing timestamps? ie., > monotonic and realtime clocks already have vdso mappings for userspace with > well known performance characteristics. Why not have perf convert its > perf_clock timestamps into monotonic or realtime when dumping events? > Can monotonic timestamps be obtained from NMI context in the kernel?
| |