From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757853AbcIPHzd (ORCPT ); Fri, 16 Sep 2016 03:55:33 -0400 Received: from foss.arm.com ([217.140.101.70]:48958 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754364AbcIPHzX (ORCPT ); Fri, 16 Sep 2016 03:55:23 -0400 Date: Fri, 16 Sep 2016 08:55:24 +0100 From: Will Deacon To: Jan Glauber Cc: Mark Rutland , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 0/5] Cavium ThunderX uncore PMU support Message-ID: <20160916075523.GJ3380@arm.com> References: <20160628102419.GA5425@arm.com> <20160628140459.GA27541@hardcore> <20160704101132.GC1639@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160704101132.GC1639@arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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