From: Ingo Molnar <mingo@elte.hu>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Robert Richter" <robert.richter@amd.com>,
"Stephane Eranian" <eranian@google.com>,
LKML <linux-kernel@vger.kernel.org>,
"Don Zickus" <dzickus@redhat.com>, acme <acme@ghostprotocols.net>,
"Frédéric Weisbecker" <fweisbec@gmail.com>,
"Thomas Gleixner" <tglx@linutronix.de>
Subject: Re: [V3][PATCH 0/7] perf, x86: Implement AMD IBS
Date: Tue, 4 Oct 2011 10:54:09 +0200 [thread overview]
Message-ID: <20111004085409.GA18566@elte.hu> (raw)
In-Reply-To: <1317716839.25926.12.camel@twins>
* Peter Zijlstra <peterz@infradead.org> wrote:
> On Fri, 2011-09-23 at 14:20 +0200, Robert Richter wrote:
> > > The only thing I'm not quite sure on is the userspace bits, but those
> > > are in the future work section as well, but possibly Ingo has a strong
> > > opinion here, sadly he doesn't have email atm :/
> >
> > With Lin's patch 'perf: Remove perf_event_attr::type check' we already
> > can sample with perf record.
> >
> > I think we could extend perf report to parse also ibs samples.
> > The only thing we need for it should be the pmu name/type mapping
> > in the perf.data header and the pmu type in the sample. See my
> > comment on Stephane's patch '[PATCH] perf: make perf.data more
> > self-descriptive (v5)'.
>
> OK, so Ingo really really wants to see a little more perf
> integration there. Acme, what's the state of Stephane's patch?
So the whole IBS thing looks quite unintegrated to me - and that's
partly because the hw is admittedly weird. The way we could perhaps
live with it upstream is two conditions:
- Testable IBS user-space code a bit more prominently integrated
than having to go down into a cellar with no working lights and
finding the code on display in tools/perf/Documentation/examples/
on the bottom of a locked filing cabinet stuck in a disused
lavatory with a sign on the door saying 'Beware of the Leopard.'
- Only root/privileged users should be able to access it. Right now
i think it's root-only due to percpu restrictions, but wanted to
mention it that this is an explicit requirement.
Non-privileged IBS use could be enabled by having working integration
with generic events: we could add a upos generic event for example so
IBS could map to '-e uops:p' or such, to allow skid-less profiling on
AMD CPUs.
Thanks,
Ingo
next prev parent reply other threads:[~2011-10-04 8:55 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-21 9:30 [V3][PATCH 0/7] perf, x86: Implement AMD IBS Robert Richter
2011-09-21 9:30 ` [V3][PATCH 1/7] perf, x86: share IBS macros between perf and oprofile Robert Richter
2011-09-21 9:30 ` [V3][PATCH 2/7] perf, x86: Implement IBS initialization Robert Richter
2011-09-21 9:30 ` [V3][PATCH 3/7] perf, x86: Implement IBS event configuration Robert Richter
2011-09-21 9:30 ` [V3][PATCH 4/7] perf, x86: Implement IBS interrupt handler Robert Richter
2011-09-22 21:51 ` Andi Kleen
2011-09-23 8:44 ` Robert Richter
2011-09-21 9:30 ` [V3][PATCH 5/7] perf, x86: Implement IBS pmu control ops Robert Richter
2011-09-21 9:30 ` [V3][PATCH 6/7] perf, x86: Implement 64 bit counter support for IBS Robert Richter
2011-09-21 9:30 ` [V3][PATCH 7/7] perf, x86: Example code for AMD IBS Robert Richter
2011-09-23 11:48 ` [V3][PATCH 0/7] perf, x86: Implement " Peter Zijlstra
2011-09-23 12:20 ` Robert Richter
2011-09-23 22:28 ` Andi Kleen
2011-09-25 15:20 ` David Ahern
2011-09-25 15:26 ` Andi Kleen
2011-09-25 15:29 ` David Ahern
2011-10-04 12:35 ` Stephane Eranian
2011-10-04 13:18 ` Andi Kleen
2011-10-04 13:20 ` Stephane Eranian
2011-10-04 8:27 ` Peter Zijlstra
2011-10-04 8:54 ` Ingo Molnar [this message]
2011-10-04 14:26 ` Robert Richter
2011-10-10 14:48 ` Robert Richter
2011-10-12 7:04 ` Ingo Molnar
2011-10-04 16:41 ` Andi Kleen
2011-10-04 16:45 ` Peter Zijlstra
2011-10-04 17:16 ` Robert Richter
2011-10-04 17:42 ` Andi Kleen
2011-10-10 6:05 ` Ingo Molnar
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=20111004085409.GA18566@elte.hu \
--to=mingo@elte.hu \
--cc=acme@ghostprotocols.net \
--cc=dzickus@redhat.com \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=robert.richter@amd.com \
--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 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.