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. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
