Messages in this thread | | | Date | Tue, 25 Aug 2009 08:31:54 +1000 | From | Paul Mackerras <> | Subject | Re: perf_counters issue with enable_on_exec |
| |
stephane eranian writes:
> As you indicated the issue is with the timing information and I think > it is not related to enable_on_exec. It is more related to the fact > that to enable a group with a single ioctl() you enable ALL BUT the > leader. But that means that the time_enabled for the !leader is > ticking. Thus scaling won't be as expected yet it is correct > given what happens internally.
No, time_enabled shouldn't be increasing for a counter that's in a group whose leader is disabled.
I'll try out your test program today.
> I think there needs to be a distinction between 'enabled immediately > but cannot run because group is not totally enabled' and 'cannot run > because the group has been multiplexed out yet all could be dispatched > because all events were dispatched'. In the former, it seems you don't > want time_enabled to tick, while in the latter you do. In other words, > time_enabled ticks for each event if the group is 'dispatch-able' (or > runnable in your terminology) otherwise it does not. time_enabled reflects > the fact that the group could run but did not have access to the PMU > resource because of contention with other groups.
Right. That is exactly what the code is supposed to do. If it doesn't there's a bug.
Paul.
| |