From: Vince Weaver <vweaver1@eecs.utk.edu>
To: Stephane Eranian <eranian@google.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>, <mingo@redhat.com>,
<hpa@zytor.com>, <linux-kernel@vger.kernel.org>,
<tglx@linutronix.de>, <mingo@elte.hu>
Subject: Re: [tip:perf/urgent] perf/x86: Enable raw event access to Intel offcore events
Date: Mon, 21 Nov 2011 16:04:08 -0500 [thread overview]
Message-ID: <alpine.DEB.2.00.1111211559190.24943@cl320.eecs.utk.edu> (raw)
In-Reply-To: <CABPqkBRHW0ZmeqADptvBySLZpi6jc_bEFKoukkA6rtd5o04ziQ@mail.gmail.com>
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@eecs.utk.edu
next prev parent reply other threads:[~2011-11-21 21:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-03 16:05 [perf] enable raw OFFCORE_EVENTS for non-perf userspace Vince Weaver
2011-08-03 17:00 ` Vince Weaver
2011-08-04 15:55 ` Peter Zijlstra
2011-08-05 2:24 ` Vince Weaver
2011-08-05 9:49 ` Ingo Molnar
2011-11-07 18:30 ` Vince Weaver
2011-11-18 23:34 ` [tip:perf/urgent] perf/x86: Enable raw event access to Intel offcore events tip-bot for Peter Zijlstra
2011-11-21 18:24 ` Vince Weaver
2011-11-21 18:52 ` Peter Zijlstra
2011-11-21 19:01 ` Vince Weaver
2011-11-21 19:04 ` Stephane Eranian
2011-11-21 21:04 ` Vince Weaver [this message]
2011-11-21 21:39 ` Stephane Eranian
2011-11-21 21:42 ` Peter Zijlstra
2011-11-21 21:45 ` Stephane Eranian
2011-11-21 21:48 ` Peter Zijlstra
2011-11-21 22:05 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.00.1111211559190.24943@cl320.eecs.utk.edu \
--to=vweaver1@eecs.utk.edu \
--cc=a.p.zijlstra@chello.nl \
--cc=eranian@google.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.