Messages in this thread | | | Date | Sat, 16 Nov 2013 19:41:34 -0800 | From | Andi Kleen <> | Subject | Re: [BUG] perf stat: explicit grouping yields unexpected results |
| |
> I'd say that the default behavior should be what Jiri implemented: get > the most out of the situation and inform. But you are right in that > 'forcing' all elements of a group to be valid should be possible as > well - if a special perf stat option or event format is used.
When something is multiplexed it can have a very large measurement error. For workloads that fluctuate quite a bit, and the fluctuations do not line up well with the multiplexing interval, the default scaling does not give good results.
So you expect to get good data, but you get very bad data.
When collecting data for a large number of events it is important to group them correctly, so that events that are directly dependent on each other in equations are properly grouped.
When explicit groups were added the user likely considered this problem, so it's not good to silently override the choices.
If a user doesn't care they can always not use groups.
> Even in that second case it shouldn't say <unsupported> for everything > in the result, but should deny the run immediately and return with an > error, and should tell the user how many events in the group fit and > which ones didn't.
Returning this information would be great, but it would really need an extended errno, or just a error string reported out.
-Andi
-- ak@linux.intel.com -- Speaking for myself only
| |