From: Ingo Molnar <mingo@elte.hu>
To: eranian@gmail.com
Cc: LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Robert Richter <robert.richter@amd.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
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: Re: IV.3 - AMD IBS
Date: Mon, 22 Jun 2009 14:00:18 +0200 [thread overview]
Message-ID: <20090622120018.GR24366@elte.hu> (raw)
In-Reply-To: <7c86c4470906161042p7fefdb59y10f8ef4275793f0e@mail.gmail.com>
> 3/ AMD IBS
>
> How is AMD IBS going to be implemented?
>
> IBS has two separate sets of registers. One to capture fetch
> related data and another one to capture instruction execution
> data. For each, there is one config register but multiple data
> registers. In each mode, there is a specific sampling period and
> IBS can interrupt.
>
> It looks like you could define two pseudo events or event types
> and then define a new record_format and read_format. That formats
> would only be valid for an IBS event.
>
> Is that how you intend to support IBS?
That is indeed one of the ways we thought of, not really nice, but
then, IBS is really weird, what were those AMD engineers thinking
:-)
The point is - weird hardware gets expressed as a ... weird feature
under perfcounters too. Not all hardware weirdnesses can be
engineered away.
next prev parent reply other threads:[~2009-06-22 12:01 UTC|newest]
Thread overview: 68+ 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 ` Ingo Molnar [this message]
2009-06-22 14:08 ` [perfmon2] IV.3 - AMD IBS 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
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
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=20090622120018.GR24366@elte.hu \
--to=mingo@elte.hu \
--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=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