Dan,
On Tue, Jun 1, 2010 at 7:13 PM, Dan Upton <up...@virginia.edu> wrote:
> I think that the example program task in libpfm4 does pretty much what I
> want it to, except I wanted to have a finer sampling period than 1 sec. I
> added an option to specify a number of microseconds and use
> usleep(sleeptime) instead of sleep(1). When I set sleeptime below 1mil
> microsec, print_counts tells me that it's scaled from, say, 95.28% of time.
> I can't quite figure that part out - what's going on with the ratios and
> scaling in print_counts, and why do we need them?
>
perf_events does automatic event multiplexing when the PMU is overcommitted.
You are also sharing the PMU with other users. For instance, task is measuring
per-thread and it has to share the PMU with any other tool/user measuring in
system-wide mode. That means that your event may not necessarily be on all
the time.
When you read out the counts, you get the raw count, i.e., the events actually
measured. You also get timing information: time_enabled, time_running.
The former measures the time between you starting and stopping the event.
The latter measures the actual time on the PMU. Thus to get an *estimate* of
the count for the entire duration you need to scale the count:
total_count = (raw_count * time_enabled)/time_running;
A sign that you have been multiplexed is that time_enabled != time_running.
You may also cause multiplexing all by yourself if you pass more events than
there are actual counters on the PMU (or if the events you pass conflict with
each other).
Hope this clarifies it for you.
------------------------------------------------------------------------------
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
