[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABPqkBQHyWUGkeu=ctGifDegUq_7oA_iFRdS-02qoGifY63F9Q@mail.gmail.com>
Date: Fri, 15 Nov 2013 23:52:10 +0100
From: Stephane Eranian <eranian@...gle.com>
To: Vince Weaver <vince@...ter.net>
Cc: Ingo Molnar <mingo@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Jiri Olsa <jolsa@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
"mingo@...e.hu" <mingo@...e.hu>, David Ahern <dsahern@...il.com>,
"ak@...ux.intel.com" <ak@...ux.intel.com>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Namhyung Kim <namhyung.kim@....com>
Subject: Re: [BUG] perf stat: explicit grouping yields unexpected results
On Fri, Nov 15, 2013 at 4:08 PM, Vince Weaver <vince@...ter.net> wrote:
> On Fri, 15 Nov 2013, Ingo Molnar wrote:
>>
>> 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.
>
> It does not, or at least I'm pretty sure it can't if the NMI watchdog is
> enabled (Stephane, are you doing your tests with NMI watchdog disabled?)
>
I think my tests were with watchdog disabled.
> This is a big problem with PAPI. If the NMI watchdog is enabled you can't
> tell if a group will fail until the first read, the kernel can't tell you
> at setup time.
>
Unless, you build the group and measure in for a short bit of time to validate
runtime execution. But then there is no guarantee either. Because the
perf_events
situation may change, e.g., you may get another pinned event. So I don't think
you will ever get that guarantee at setup time. I goes back to the core design
idea behind perf_events.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists