From: Eric Dumazet <dada1@cosmosbay.com>
To: eranian@gmail.com
Cc: Andi Kleen <andi@firstfloor.org>,
Mikael Pettersson <mikpe@it.uu.se>,
Robert Richter <robert.richter@amd.com>,
oprofile-list@lists.sf.net, Ingo Molnar <mingo@elte.hu>,
Jiri Kosina <jkosina@suse.cz>, Jiri Benc <jbenc@suse.cz>,
Vilem Marsik <vmarsik@suse.cz>,
Pekka Enberg <penberg@cs.helsinki.fi>,
linux-kernel@vger.kernel.org
Subject: Re: Oprofile : need to adjust PC by 16 bytes
Date: Mon, 17 Nov 2008 16:16:23 +0100 [thread overview]
Message-ID: <49218AC7.20202@cosmosbay.com> (raw)
In-Reply-To: <7c86c4470811170702y127c9249m9b86b65a38a3e05c@mail.gmail.com>
stephane eranian a écrit :
> Hello,
>
> I have not seen the beginning of that discussion so my comments may be
> slightly off.
> It seems Eric has problems with accuracy of instruction addresses when
> sampling with the PMU.
>
> This is an inherent limitation of the PMU. It can be mitigated but not
> completely eliminated. The core
> issue is that it takes several cycles between the moment a counter
> overflows and posting of the PMU
> interrupt. During that time, the CPU keeps on executing instructions.
> The interrupt IP you get, reflects
> the place you were when it triggered. That can be far away from where
> it was posted and where the
> counter actually overflowed. Of course, if you are stalled that
> distance is usually 0 or off by a small
> number of instructions. But it can be very large when overflow happens
> during a kernel critical section
> where interrupts are off. There is nothing SW can do about all of this.
>
> Andi mentioned PEBS. I don't know if you are familiar with what it
> does. Let me summarize. This is
> a hardware/microcode feature which implements a hardware-managed
> buffer where samples are
> stored. The OS points the CPU to a memory region where PMU samples are
> stored. No PMU
> interrupt is generated until the buffer becomes full. That part
> addresses some of the overhead
> associated with interrupt-based sampling. Unfortunately, PEBS does
> not point to the instruction where
> the counter overflowed, it will still be a few instructions off. But
> this time, you get the machine state at the
> last retired instruction. Furthermore, PEBS can record samples while
> in kernel critical sections. A limitation
> of PEBS is that it does not work with all the PMU events. Only a
> handful are available.
>
> As for perfmon, if you pull from the perfmon2 GIT tree, this should
> work. Don't know what happen in
> you case.
>
> Perfmon and the pfmon can do simple counting or also collect profiles.
>
> $ pfmon date
>
> Counts cycles at the user level only for the process date
>
> $ pfmon --system-wide -t10
>
> Counts elapsed cycles at user level for all CPU for 10s. Results are per-cpu
>
> $ pfmon --long-smpl-periods=240000 date
>
> Collect a flat profile of process date. Period is 240,000 elapsed user cycle
>
> $ pfmon --system-wide --long-smpl-periods=240000 -t 10
>
> Collect a flat profile on each online CPU during 10s. Period is
> 240,000 user elapsed cycles. Results are per-cpu
>
> You have a lot more examples on the perfmon web site, Following the
> documentation and pfmon users' guide.
>
> Perfmon/pfmon can use PEBS on Intel Core processors. First step is to
> insert the kernel module for it:
> # modprobe perfmon_pebs_core_smpl
>
> Then use pfmon, we use instruction_retired because elapsed cycles does
> not support PEBS:
>
> $ pfmon --smpl-module=pebs -einstructions_retired
> --long-smpl-periods=120000 date
>
> Hope this helps.
>
Sure it does ! Thanks a lot Stephane, I am going to try all this stuff.
next prev parent reply other threads:[~2008-11-17 15:17 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-13 20:57 Oprofile [still] doesn't work on 2.6.28-rc4 on certain CPU Jiri Kosina
2008-11-13 21:24 ` Ingo Molnar
2008-11-13 21:27 ` Jiri Kosina
2008-11-13 21:37 ` Ingo Molnar
2008-11-13 21:49 ` Eric Dumazet
2008-11-14 15:25 ` Oprofile : need to adjust PC by 16 bytes Eric Dumazet
2008-11-14 15:59 ` Andi Kleen
2008-11-14 16:02 ` Eric Dumazet
2008-11-14 17:01 ` Mikael Pettersson
2008-11-14 17:21 ` Eric Dumazet
2008-11-14 17:50 ` Andi Kleen
2008-11-15 16:30 ` Eric Dumazet
2008-11-15 18:36 ` Andi Kleen
2008-11-17 15:02 ` stephane eranian
2008-11-17 15:16 ` Eric Dumazet [this message]
2008-11-17 15:24 ` Andi Kleen
2008-11-14 10:09 ` Oprofile [still] doesn't work on 2.6.28-rc4 on certain CPU Robert Richter
2008-11-14 11:12 ` Jiri Kosina
2008-11-13 21:33 ` Maynard Johnson
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=49218AC7.20202@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=andi@firstfloor.org \
--cc=eranian@gmail.com \
--cc=jbenc@suse.cz \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=mikpe@it.uu.se \
--cc=mingo@elte.hu \
--cc=oprofile-list@lists.sf.net \
--cc=penberg@cs.helsinki.fi \
--cc=robert.richter@amd.com \
--cc=vmarsik@suse.cz \
/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