linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/5] Cavium ThunderX uncore PMU support
Date: Fri, 16 Sep 2016 08:55:24 +0100	[thread overview]
Message-ID: <20160916075523.GJ3380@arm.com> (raw)
In-Reply-To: <20160704101132.GC1639@arm.com>

Hi Jan,

On Mon, Jul 04, 2016 at 11:11:32AM +0100, Will Deacon wrote:
> On Tue, Jun 28, 2016 at 04:04:59PM +0200, Jan Glauber wrote:
> > On Tue, Jun 28, 2016 at 11:24:20AM +0100, Will Deacon wrote:
> > > On Wed, Mar 09, 2016 at 05:21:02PM +0100, Jan Glauber wrote:
> > > > This patch series provides access to various counters on the ThunderX SOC.
> > > > 
> > > > For details of the uncore implementation see patch #1.
> > > > 
> > > > Patches #2-5 add the various ThunderX specific PMUs.
> > > > 
> > > > As suggested I've put the files under drivers/perf/uncore. I would
> > > > prefer this location over drivers/bus because not all of the uncore
> > > > drivers are bus related.
> > > 
> > > What's the status of these patches? Were you planning to send a new
> > > version?
> >
> > I was half-way through with addressing Mark's review comments when
> > got side-tracked.
> > 
> > The principle question these patches raised remains open though in my
> > opinion, how to determine the socket a device belongs to.
> > 
> > There is no first-class interface to ask a device or the firmware
> > which socket the device lives on.
> > 
> > The options I see are:
> > A) Using NUMA node information, depends on CONFIG_NUMA
> > B) Decoding the socket bits of the PCI BAR address
> > C) Using PCI topology information
> > 
> > A is what I tried, but I agree that depending on CONFIG_NUMA is not a good
> > solution. B would be easy but looks not very future-proof. So option C
> > is what is left...
> 
> Sorry to go full circle on this, but "depends on NUMA" sounds better
> than deriving NUMA topology from PCI to me. The only worry I have is if
> the NUMA information ends up being insufficient in the long-term, and we
> end up with a mixture of the three options above in order to figure out
> the PMU topology.
> 
> As long as you're happy that the PMU:NUMA topology remains 1:1, then I
> have no objections. The moment you need extra hacks on the side, we should
> probably drop the NUMA dependency altogether and figure it out some other
> way.

Any news on this series, or did I miss a v3? I was hoping to have this in
for 4.9, but it seems to have stalled :(

Will

  reply	other threads:[~2016-09-16  7:55 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-09 16:21 [PATCH v2 0/5] Cavium ThunderX uncore PMU support Jan Glauber
2016-03-09 16:21 ` [PATCH v2 1/5] arm64/perf: Basic uncore counter support for Cavium ThunderX Jan Glauber
2016-04-19 15:06   ` Mark Rutland
2016-04-20 12:29     ` Jan Glauber
2016-03-09 16:21 ` [PATCH v2 2/5] arm64/perf: Cavium ThunderX L2C TAD uncore support Jan Glauber
2016-04-19 15:43   ` Mark Rutland
2016-03-09 16:21 ` [PATCH v2 3/5] arm64/perf: Cavium ThunderX L2C CBC " Jan Glauber
2016-04-19 15:56   ` Mark Rutland
2016-03-09 16:21 ` [PATCH v2 4/5] arm64/perf: Cavium ThunderX LMC " Jan Glauber
2016-03-09 16:21 ` [PATCH v2 5/5] arm64/perf: Cavium ThunderX OCX TLK " Jan Glauber
2016-04-04 12:19 ` [PATCH v2 0/5] Cavium ThunderX uncore PMU support Jan Glauber
2016-04-25 11:22   ` Will Deacon
2016-04-25 12:02     ` Jan Glauber
2016-04-25 13:19       ` Will Deacon
2016-04-26 12:08         ` Jan Glauber
2016-04-26 13:53           ` Will Deacon
2016-04-27 10:51             ` Jan Glauber
2016-04-27 11:18               ` Mark Rutland
     [not found] ` <CAEiAFz3eCsX3VoNus_Rq+En5zuB8fAxNCbC3ktw2NqLKwC=_kA@mail.gmail.com>
2016-04-19 10:35   ` Jan Glauber
2016-04-19 16:03     ` Mark Rutland
2016-06-28 10:24 ` Will Deacon
2016-06-28 14:04   ` Jan Glauber
2016-07-04 10:11     ` Will Deacon
2016-09-16  7:55       ` Will Deacon [this message]
2016-09-16  8:39         ` Jan Glauber

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=20160916075523.GJ3380@arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).