From: Ingo Molnar <mingo@elte.hu>
To: eranian@gmail.com
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Rob Fowler <rjf@renci.org>, Philip Mucci <mucci@eecs.utk.edu>,
LKML <linux-kernel@vger.kernel.org>,
Andi Kleen <andi@firstfloor.org>,
Paul Mackerras <paulus@samba.org>,
Maynard Johnson <mpjohn@us.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
perfmon2-devel <perfmon2-devel@lists.sourceforge.net>
Subject: Re: [perfmon2] IV.3 - AMD IBS
Date: Tue, 23 Jun 2009 16:55:08 +0200 [thread overview]
Message-ID: <20090623145508.GC13415@elte.hu> (raw)
In-Reply-To: <7c86c4470906230725t2d86cd2eybabeba454f3aff81@mail.gmail.com>
* stephane eranian <eranian@googlemail.com> wrote:
> On Tue, Jun 23, 2009 at 4:05 PM, Ingo Molnar<mingo@elte.hu> wrote:
> >
> > * stephane eranian <eranian@googlemail.com> wrote:
> >
> >> > The most natural way to support IBS would be to have a special
> >> > sampling cycle counter and use that as group lead and add non
> >> > sampling siblings to that group to get individual elements.
> >> >
> >> As discussed in my message, I think the way to support IBS is to
> >> create two pseudo-events (like your perf_hw_event_ids), one for
> >> fetch and one for op (because they could be measured
> >> simultaneously). The sample_period field would be used to express
> >> the IBS*CTL maxcnt, subject to the verification that the bottom 4
> >> bits must be 0. And then, you add two new sampling formats
> >> PERF_SAMPLE_IBSFETCH, PERF_SAMPLE_IBSOP. Those would only work
> >> with IBS pseudo events. Once you have the randomize option in
> >> perf_counter_attr, you could even enable IBSFETCH randomization.
> >
> > I'd suggest to start smaller, and first express the 'precise'
> > nature of IBS transparently, by simply mapping it to one of the
> > generic events. (cycles and instructions both appears to be
> > possible)
>
> IBS is precise by nature.
(yes. Did you understand my comments above as saying the opposite?)
> [...] It does not work like PEBS. It tags an instruction and then
> collects info about it. When it retires, IBS freezes and triggers
> an interrupt like a regular counter interrupt. Except this time,
> you don't care about the interrupted IP, you use the instruction
> address in the IBS data register, it is guaranteed to correspond
> to the tagged instruction.
>
> The sampling period expresses the delay before picking the
> instruction to tag. And as I said before, it is only 20 bits and
> the bottom 4 bits must be zero (as they cannot be encoded).
The 20 bits delay is in cycles, right? So this in itself still lends
itself to be transparently provided as a PERF_COUNT_HW_CPU_CYCLES
counter.
Ingo
next prev parent reply other threads:[~2009-06-23 14:55 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-16 17:42 v2 of comments on Performance Counters for Linux (PCL) stephane eranian
2009-06-22 11:48 ` Ingo Molnar
2009-06-22 11:49 ` I.1 - System calls - ioctl Ingo Molnar
2009-06-22 12:58 ` Christoph Hellwig
2009-06-22 13:56 ` Ingo Molnar
2009-06-22 17:41 ` Arnd Bergmann
2009-07-13 10:53 ` Peter Zijlstra
2009-07-13 17:30 ` [perfmon2] " Arnd Bergmann
2009-07-13 17:34 ` Peter Zijlstra
2009-07-13 17:53 ` Arnd Bergmann
2009-07-14 13:51 ` Christoph Hellwig
2009-07-30 13:58 ` stephane eranian
2009-07-30 14:13 ` Peter Zijlstra
2009-07-30 16:17 ` stephane eranian
2009-07-30 16:40 ` Arnd Bergmann
2009-07-30 16:53 ` stephane eranian
2009-07-30 17:20 ` Arnd Bergmann
2009-08-03 14:22 ` Peter Zijlstra
2009-06-22 11:50 ` I.2 - Grouping Ingo Molnar
2009-06-22 19:45 ` stephane eranian
2009-06-22 22:04 ` Corey Ashford
2009-06-23 17:51 ` stephane eranian
2009-06-22 21:38 ` Corey Ashford
2009-06-23 5:16 ` Paul Mackerras
2009-06-23 7:36 ` stephane eranian
2009-06-23 8:26 ` Paul Mackerras
2009-06-23 8:30 ` stephane eranian
2009-06-23 16:24 ` Corey Ashford
2009-06-22 11:51 ` I.3 - Multiplexing and system-wide Ingo Molnar
2009-06-22 11:51 ` I.4 - Controlling group multiplexing Ingo Molnar
2009-06-22 11:52 ` I.5 - Mmaped count Ingo Molnar
2009-06-22 12:25 ` stephane eranian
2009-06-22 12:35 ` Peter Zijlstra
2009-06-22 12:54 ` stephane eranian
2009-06-22 14:39 ` Peter Zijlstra
2009-06-23 0:41 ` Paul Mackerras
2009-06-23 0:39 ` Paul Mackerras
2009-06-23 6:13 ` Peter Zijlstra
2009-06-23 7:40 ` stephane eranian
2009-06-23 0:33 ` Paul Mackerras
2009-06-22 11:53 ` I.6 - Group scheduling Ingo Molnar
2009-06-22 11:54 ` I.7 - Group validity checking Ingo Molnar
2009-06-22 11:54 ` I.8 - Generalized cache events Ingo Molnar
2009-06-22 11:55 ` I.9 - Group reading Ingo Molnar
2009-06-22 11:55 ` I.10 - Event buffer minimal useful size Ingo Molnar
2009-06-22 11:56 ` I.11 - Missing definitions for generic events Ingo Molnar
2009-06-22 14:54 ` stephane eranian
2009-06-22 11:57 ` II.1 - Fixed counters on Intel Ingo Molnar
2009-06-22 14:27 ` stephane eranian
2009-06-22 11:57 ` II.2 - Event knowledge missing Ingo Molnar
2009-06-23 13:18 ` stephane eranian
2009-06-22 11:58 ` III.1 - Sampling period randomization Ingo Molnar
2009-06-22 11:58 ` IV.1 - Support for model-specific uncore PMU Ingo Molnar
2009-06-22 11:59 ` IV.2 - Features impacting all counters Ingo Molnar
2009-06-22 12:00 ` IV.3 - AMD IBS Ingo Molnar
2009-06-22 14:08 ` [perfmon2] " Rob Fowler
2009-06-22 17:58 ` Maynard Johnson
2009-06-23 6:19 ` Peter Zijlstra
2009-06-23 8:19 ` stephane eranian
2009-06-23 14:05 ` Ingo Molnar
2009-06-23 14:25 ` stephane eranian
2009-06-23 14:55 ` Ingo Molnar [this message]
2009-06-23 14:40 ` Rob Fowler
2009-06-22 19:17 ` stephane eranian
2009-06-22 12:00 ` IV.4 - Intel PEBS Ingo Molnar
2009-06-22 12:16 ` Andi Kleen
2009-06-22 12:01 ` IV.5 - Intel Last Branch Record (LBR) Ingo Molnar
2009-06-22 20:02 ` stephane eranian
-- strict thread matches above, loose matches on Subject: below --
2009-06-25 11:28 [perfmon2] IV.3 - AMD IBS 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=20090623145508.GC13415@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=eranian@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpjohn@us.ibm.com \
--cc=mucci@eecs.utk.edu \
--cc=paulus@samba.org \
--cc=perfmon2-devel@lists.sourceforge.net \
--cc=rjf@renci.org \
--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