Date: Mon, 25 Apr 2016 14:19:07 +0100
From: Will Deacon <will.deacon@arm.com>
To: Jan Glauber <jan.glauber@caviumnetworks.com>
Cc: Mark Rutland <mark.rutland@arm.com>, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 0/5] Cavium ThunderX uncore PMU support
Message-ID: <20160425131907.GB30830@arm.com>
References: <cover.1457539621.git.jglauber@cavium.com>
 <20160404121954.GA9300@hardcore>
 <20160425112207.GL16065@arm.com>
 <20160425120222.GA2552@hardcore>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160425120222.GA2552@hardcore>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1464
Lines: 32

On Mon, Apr 25, 2016 at 02:02:22PM +0200, Jan Glauber wrote:
> On Mon, Apr 25, 2016 at 12:22:07PM +0100, Will Deacon wrote:
> > On Mon, Apr 04, 2016 at 02:19:54PM +0200, Jan Glauber wrote:
> > > can you have a look at these patches?
> > 
> > Looks like Mark reviewed this last week -- are you planning to respin?
> 
> Yes, of course. I just had no time yet and I'm a bit lost on how to
> proceed without using the NUMA node information which Mark did not like
> to be used.
> 
> The only way to know which device is on which node would be to look
> at the PCI topology (which is also the source of the NUMA node_id).
> We could do this manually in order to not depend on CONFIG_NUMA,
> but I would like to know if that is acceptable before respinning the
> patches.

That doesn't feel like it really addresses Mark's concerns -- it's just
another way to get the information that isn't a first-class PMU topology
description from firmware.

Now, I don't actually mind using the NUMA topology so much in the cases
where it genuinely correlates with the PMU topology. My objection is more
that we end up sticking everything on node 0 if !CONFIG_NUMA, which could
result in working with an incorrect PMU topology and passing all of that
through to userspace.

So I'd prefer either making the driver depend on NUMA, or at the very least
failing to probe  the PMU if we discover a socketed system and NUMA is not
selected. Do either of those work as a compromise?

Will