From: Jacob Shin <jacob.shin@amd.com>
To: Robert Richter <rric@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Paul Mackerras <paulus@samba.org>, Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Stephane Eranian <eranian@google.com>, <x86@kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/4] perf, amd: Enable AMD family 15h northbridge counters
Date: Sun, 11 Nov 2012 12:44:26 -0600 [thread overview]
Message-ID: <20121111184426.GA5415@jshin-Toonie> (raw)
In-Reply-To: <20121110115027.GC2777@rric.localhost>
On Sat, Nov 10, 2012 at 12:50:27PM +0100, Robert Richter wrote:
> On 09.11.12 19:01:34, Jacob Shin wrote:
> > The following patchset enables 4 additional performance counters in
> > AMD family 15h processors that counts northbridge events -- such as
> > DRAM accesses.
> >
> > This patchset is based on previous work done by Robert Richter
> > <rric@kernel.org> :
> >
> > https://lkml.org/lkml/2012/6/19/324
>
> The original patch set of this is here (a rebased version):
>
> http://git.kernel.org/?p=linux/kernel/git/rric/oprofile.git;a=shortlog;h=refs/heads/perf-nb
>
> This code was tested in detail.
>
> > The main differences are:
> >
> > - The northbridge counters are indexed contiguously right above the
> > core performance counters.
> >
> > - MSR address offset calculations are moved to architecture specific
> > files.
> >
> > - Interrups are set up to be delivered only to a single core.
>
> So I rather suggest to make delta patches on top of my patches.
Okay, if we have to, I can rework my patches on top of that, as long
as the end result looks something like I'm suggesting above. Because
in an upcoming processor family, there is no core performance counter
extensions, but we do have northbridge performance counters. Meaning
the counter address base would be c0010000 and northbridge counters
live in c0010240, being 0x240 apart, we could make counter masks work
but that testng awful alot of 0's for every address offset calculation
.
>
> Peter's main concerns were that my patch set is not in the
> Intel-uncore style. I started reworking this but was not able to
> finish my work. This concerns still exist.
Right, I considered this too, and still, I agree with you Robert that
it makes more sense to just extend AMD's x86 PMU.
1. Because the hardware interface -- register bit fields, are alost
identical
2. Because the interrupt delivery mechanism is also identical --
delivered via same APIC interrupt vector.
I think my proposed patchset on top of current Linus's tree is pretty
minimal, and is isolated to AMD so it should be easier to swallow.
Peter, could you take a look at the patchset and if you still prefer
a intel uncore like implementation?
>
> Due to the current situation I would rather prefer to create a
> tip:perf/amd-nb branch that includes my patches and then add all
> further necessary steps for mainline acceptance on top of it.
Okay, Peter, let me know if this is a route to go, and I'll generate
my patchset on top of that.
Thanks,
-Jacob
>
> Thanks,
>
> -Robert
>
next prev parent reply other threads:[~2012-11-11 18:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-10 1:01 [PATCH 0/4] perf, amd: Enable AMD family 15h northbridge counters Jacob Shin
2012-11-10 1:01 ` [PATCH 1/4] perf, amd: Simplify northbridge event constraints handler Jacob Shin
2012-11-10 1:01 ` [PATCH 2/4] perf, amd: Refactor northbridge event constraints handler for code sharing Jacob Shin
2012-11-10 1:01 ` [PATCH 3/4] perf, x86: Move MSR address offset calculation to architecture specific files Jacob Shin
2012-11-10 1:01 ` [PATCH 4/4] perf, amd: Enable northbridge performance counters on AMD family 15h Jacob Shin
2012-11-10 11:50 ` [PATCH 0/4] perf, amd: Enable AMD family 15h northbridge counters Robert Richter
2012-11-11 18:17 ` Stephane Eranian
2012-11-12 14:36 ` Robert Richter
2012-11-11 18:44 ` Jacob Shin [this message]
2012-11-12 12:24 ` Stephane Eranian
2012-11-12 14:22 ` Robert Richter
2012-11-12 16:13 ` Jacob Shin
2012-11-12 21:08 ` Stephane Eranian
2012-11-12 14:55 ` Robert Richter
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=20121111184426.GA5415@jshin-Toonie \
--to=jacob.shin@amd.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@ghostprotocols.net \
--cc=eranian@google.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paulus@samba.org \
--cc=rric@kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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