Re: Understanding timestamps in perf.data

[Dennis Gnad <dennis.gnad@kit.edu>]

On 02.09.2015 19:00, Vince Weaver wrote:
> They might not be relevant for profiling, but some people use the perf
> counters for other tasks.
>
> For example, when measuring phase plot behavior for a system, it would be
> great if you'd be able to say I want a snapshot sample of the cycle and
> instruction counters every 10ms, and then you can plot the CPI behavior of
> the system.

Yeah, actually I wasn't asking about profiling, sorry if this was 
misunderstood for some reason. I am looking into something you could 
call 'workload characterization' and really need the absolute 
performance counter values, as they could for example correlate with the 
resulting temperature or energy-optimal frequency of the cpu/system, 
depending on its specific workload.

> as far as I can tell you can't really do this with perf (the -I option
> only lets you get down to 100ms).

Which -I option do you mean? At least it's not available for my perf 
record (kernel 3.16).

> I ended up trying to write a custom program to do this, but it turns out
> the perf sampling interface has really high overhead when doing this, and
> the interrupt throttle kicks in which makes it useless.

Are you talking about the kernel interface or some interface of the perf 
tool? I think I need a minimum of 100Hz or 1000Hz, but it wouldn't be a 
problem if this is just collected in some kernel shared memory and in 
the end copied to userspace, or at a lower frequency.

> It's a shame, as the old "pfmon" tool that came with perfmon2 could do
> this kind of measurement very easily.
>
> Vince
>

This can not be used with current kernels, I guess? I tried "oprofile" 
before, which can show absolute counts, but instead doesn't support any 
timestamps.

So, it seems there is nothing available that can do what I need. Maybe 
some of you can still recommend where I could start looking next or go 
into more detail? Kernel, perf, oprofile, libpapi are the things that 
come to my mind. If the kernel interface is really the bottleneck, it 
probably has to be there.

Thanks for your help so far,
Dennis