[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1111211559190.24943@cl320.eecs.utk.edu>
Date: Mon, 21 Nov 2011 16:04:08 -0500
From: Vince Weaver <vweaver1@...s.utk.edu>
To: Stephane Eranian <eranian@...gle.com>
CC: Peter Zijlstra <a.p.zijlstra@...llo.nl>, <mingo@...hat.com>,
<hpa@...or.com>, <linux-kernel@...r.kernel.org>,
<tglx@...utronix.de>, <mingo@...e.hu>
Subject: Re: [tip:perf/urgent] perf/x86: Enable raw event access to Intel
offcore events
On Mon, 21 Nov 2011, Stephane Eranian wrote:
> > We have a workaround, but it currently disables kernel multiplexing and a
> > few other nice features.
>
> I don't understand why you have a problem with NMI watchdog. Multiplexing
> allows you to still measure more events than there are counters.
The PAPI code currently uses FORMAT_GROUP and puts as many events as
possible in a group. The way we maximize events in a group is to
add events until perf_events indicates a failure.
When NMI watchdog is enabled, a counter is stolen. Yet the perf_events
code does not account for this.
So say on an AMD machine with 4 counters (3 after one is stolen)
perf_events lets you add 4 events to an event group, even though only 3
are available. It does not report failure upon open or start, only at
read. By then it's too late.
We have to work around this, by doing an extra read at open time to verify
that the event group actually is valid, adding overhead.
Our multiplex code tries to maximize the number of events in a group too.
Currently PAPI works around this by just not doing kernel multiplexing
if a NMI watchdog is detected. There's probably more elegant solutions
such as checking with a read there too, or not using FORMAT_GROUP at all,
but since this is an ABI regression I was hoping it would get fixed
quickly enough that I wouldn't have to construct better workarounds.
Vince
vweaver1@...s.utk.edu
--
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