All of lore.kernel.org
 help / color / mirror / Atom feed
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.



  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 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.