From: Robert Richter <robert.richter@amd.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>,
Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 5/5] perf, x86: Add support for AMD family 15h core counters
Date: Thu, 3 Feb 2011 10:00:01 +0100 [thread overview]
Message-ID: <20110203090001.GG5874@erda.amd.com> (raw)
In-Reply-To: <AANLkTikdLUkv3y6-g=OegtJD5bXS0vPPjLMR1jmQjCZz@mail.gmail.com>
On 02.02.11 17:44:22, Stephane Eranian wrote:
> On Wed, Feb 2, 2011 at 6:29 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Wed, 2011-02-02 at 18:24 +0100, Robert Richter wrote:
> >> On 02.02.11 12:03:18, Peter Zijlstra wrote:
> >> > Why this and not something like x86_pmu.perfctr + (index << 1)?
> >> > You could even use alternatives.
> >>
> >> I was thinking about this. The main reason is the implementation of
> >> northbridge counters, the range is in MSRC001_02[47:40]. This would
> >> add more complexity then. Using a table would be something like
> >>
> >> unsigned int eventsel_f15h[] = {
> >> MSR_F15H_PERF_CTL,
> >> MSR_F15H_PERF_CTL + 2,
> >> MSR_F15H_PERF_CTL + 4,
> >> MSR_F15H_PERF_CTL + 6,
> >> MSR_F15H_PERF_CTL + 8,
> >> MSR_F15H_PERF_CTL + 10,
> >> MSR_F15H_NB_PERF_CTL,
> >> MSR_F15H_NB_PERF_CTL + 2,
> >> MSR_F15H_NB_PERF_CTL + 6,
> >> MSR_F15H_NB_PERF_CTL + 8,
> >> };
> >>
> >> We don't need to change the address generation for this. Otherwise we
> >> need to introduce more logic for the calculation.
> >>
> >> Also, were could be potential easier implementations for fixed
> >> counters, BTS, P4, IBS, etc. But didn't look that close at it.
> >>
> >> (Btw, I am not yet sure if NB counters shouldn't better start at index
> >> 16 or so to reserve space for perf counter expansion.)
> >
> > Now that the NB PMU is completely separate from the core PMU, wouldn't
> > it make more sense to implement that as a separate entity just like the
> > intel uncore bits?
>
> I agree on this.
Peter,
ok, nb events may be implemented independent from core events in a
separate struct pmu.
I still would prefer a lookup table for counter addresses. Adding a
shift parameter to struct x86_pmu to do a
addr = base + (index << shift)
seems to me a quite special solution that may not be reused in other
implementations, while a lookup table is more generic. I also don't
see a performance or memory impact there.
Anyway, a shift parameter would work too. What do you think?
-Robert
--
Advanced Micro Devices, Inc.
Operating System Research Center
next prev parent reply other threads:[~2011-02-03 9:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-02 16:40 [PATCH 0/5] perf, x86: perf, x86: Add support for AMD family 15h core counters Robert Richter
2011-02-02 16:40 ` [PATCH 1/5] perf, x86: Use helper function in x86_pmu_enable_all() Robert Richter
2011-02-16 13:47 ` [tip:perf/core] " tip-bot for Robert Richter
2011-02-02 16:40 ` [PATCH 2/5] perf, x86: Calculate perfctr msr addresses in helper functions Robert Richter
2011-02-16 13:48 ` [tip:perf/core] " tip-bot for Robert Richter
2011-02-02 16:40 ` [PATCH 3/5] perf, x86: Add new AMD family 15h msrs to perfctr reservation code Robert Richter
2011-02-16 13:48 ` [tip:perf/core] " tip-bot for Robert Richter
2011-02-02 16:40 ` [PATCH 4/5] perf, x86: Store perfctr msr addresses in config_base/event_base Robert Richter
2011-02-16 13:48 ` [tip:perf/core] " tip-bot for Robert Richter
2011-02-02 16:41 ` [PATCH 5/5] perf, x86: Add support for AMD family 15h core counters Robert Richter
2011-02-02 17:03 ` Peter Zijlstra
2011-02-02 17:24 ` Robert Richter
2011-02-02 17:29 ` Peter Zijlstra
2011-02-02 22:44 ` Stephane Eranian
2011-02-03 9:00 ` Robert Richter [this message]
2011-02-03 9:38 ` Peter Zijlstra
2011-02-03 14:06 ` Robert Richter
2011-02-15 13:52 ` [PATCH] " Robert Richter
2011-02-16 13:49 ` [tip:perf/core] " tip-bot for Robert Richter
2011-02-02 20:38 ` [PATCH 0/5] perf, x86: " 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=20110203090001.GG5874@erda.amd.com \
--to=robert.richter@amd.com \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.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 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.