Messages in this thread | | | Date | Fri, 15 Nov 2013 10:24:02 +0100 | Subject | Re: [BUG] perf stat: explicit grouping yields unexpected results | From | Stephane Eranian <> |
| |
On Fri, Nov 15, 2013 at 7:34 AM, Ingo Molnar <mingo@kernel.org> wrote: > > * Stephane Eranian <eranian@google.com> wrote: > >> Jiri, >> >> I was trying the grouping support in perf stat and I was surprised >> to see that if I create a group that is too big to be scheduled, and >> where only N out of P events can fit, perf stat still yields counts >> for the N events. I was expecting 0 counts or <not supported>. >> >> The kernel semantic is to schedule all the events in a group or >> none. Perf does something different and this is confusing. If you >> use explicit grouping then I think you want to group to fail if not >> all the events can be scheduled: >> >> On an IvyBridge: >> $ perf stat --g -e >> '{cycles,instructions,branches,branches,branches,branches,branches}' >> noploop 1 >> 3 229 417 079 cycles >> 3 223 919 023 instructions # 1,00 insns per cycle >> 3 220 868 098 branches >> 3 220 868 098 branches >> 3 220 868 098 branches >> 3 220 868 098 branches >> <not supported> branches >> >> I think it should be: <not supported> for all events. > > Btw., does the kernel side currently support discovery of such > impossible group scheduling constraints at group setup time? If not > then it probably should and it should reject them straight away. > The kernel does validate events as they are added to a group. That's why we have validate_event(), validate_group() and the fake_cpuc mode.
| |