Re: [BUG] perf stat: explicit grouping yields unexpected results

[Andi Kleen <ak@linux.intel.com>]

> 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