From: stephane eranian <eranian@googlemail.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Robert Richter <robert.richter@amd.com>,
Paul Mackerras <paulus@samba.org>,
Andi Kleen <andi@firstfloor.org>,
Maynard Johnson <mpjohn@us.ibm.com>, Carl Love <cel@us.ibm.com>,
Corey J Ashford <cjashfor@us.ibm.com>,
Philip Mucci <mucci@eecs.utk.edu>,
Dan Terpstra <terpstra@eecs.utk.edu>,
perfmon2-devel <perfmon2-devel@lists.sourceforge.net>
Subject: perf_counters issue remapped count
Date: Wed, 12 Aug 2009 00:04:09 +0200 [thread overview]
Message-ID: <7c86c4470908111504i3a1e83b9k140fdaa717584a30@mail.gmail.com> (raw)
Hi,
I am trying to use the remapped counter feature
on Intel Core. It does not work as expected.
Well, in fact, it segfaults immediately, but that's because
you have not enabled PCE in cr4. But assume you have
for a moment. Them there are still several problems.
1/ hdr->index does not work with fixed counters
On Intel, RDPMC supports fixed counters, however, you
have to add an offset 0x40000000 to the index (see Intel
Vol 2b RDPMC description).
From what I can see in:
static int perf_counter_index(struct perf_counter *counter)
{
if (counter->state != PERF_COUNTER_STATE_ACTIVE)
return 0;
return counter->hw.idx + 1 - PERF_COUNTER_INDEX_OFFSET;
}
It cannot be made to work for both generic and fixed counters.
I think this function has to go in arch-specific code or become
more complicated.
2/ rdpmc() + offset returns bogus counts
Suppose you are using a generic counter, RDPMC returns the live
40-bit value of the counter. Then, my understanding is that you are
supposed to addr hdr->offset to that value to reconstruct the full
64-bit value.
It appears this is not quite working. Here is small example counting
PERF_COUNT_HW_BRANCH_INSTRUCTIONS.
RDPMC RAW hdr->offset
34a1 offset=0x0
3bac offset=0x0
40e4 offset=0x0
461c offset=0x0
4b54 offset=0x0
508c offset=0x0
55c4 offset=0x0
5afc offset=0x0
6034 offset=0x0
656c offset=0x0
6aa4 offset=0x0
6fdc offset=0x0
7514 offset=0x0
7a4c offset=0x0
7f84 offset=0x0
84bc offset=0x0
89f4 offset=0x0
8f2c offset=0x0
9464 offset=0x0
999c offset=0x0
9ed4 offset=0x0
ac20 offset=0x0
ff8000bbe9 offset=0x7fffffff
ff8000bf15 offset=0x7fffffff
ff8000c241 offset=0x7fffffff
ff8000c56d offset=0x7fffffff
ff8000c899 offset=0x7fffffff
ff8000cbc5 offset=0x7fffffff
ff8000cef1 offset=0x7fffffff
ff8000d21d offset=0x7fffffff
ff8000d549 offset=0x7fffffff
It appears at some point, the live value of the counter is changed and suddenly
you set bit 31 (bit32-39 are sign extension). Don't think it is because of PMU
interrupt, I suspect something wrong during context switching.
The core of my loop is as follows:
for(;;) {
for (i=0; i < num; i++) {
uint64_t offset = 0;
uint64_t values[3];
do {
seq = hdr->lock;
barrier();
if (hdr->index > 0) {
values[0] = rdpmc(hdr->index-1);
offset = hdr->offset;
//values[0] += offset;
values[1] = hdr->time_enabled;
values[2] = hdr->time_running;
} else {
ret = read(fd, values, sizeof(values));
break;
}
barrier();
} while (hdr->lock != seq);
if (values[2])
values[0]=
(uint64_t)((double)values[0] * values[1]/values[2]);
printf("%20"PRIx64" offset=0x%"PRIx64"\n",
values[0],
offset);
}
fib(10);
}
next reply other threads:[~2009-08-11 22:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-11 22:04 stephane eranian [this message]
2009-08-13 9:56 ` Ingo Molnar
2009-08-13 11:14 ` stephane eranian
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=7c86c4470908111504i3a1e83b9k140fdaa717584a30@mail.gmail.com \
--to=eranian@googlemail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=cel@us.ibm.com \
--cc=cjashfor@us.ibm.com \
--cc=eranian@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mpjohn@us.ibm.com \
--cc=mucci@eecs.utk.edu \
--cc=paulus@samba.org \
--cc=perfmon2-devel@lists.sourceforge.net \
--cc=robert.richter@amd.com \
--cc=terpstra@eecs.utk.edu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®