From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751805AbcGOQRJ (ORCPT ); Fri, 15 Jul 2016 12:17:09 -0400 Received: from foss.arm.com ([217.140.101.70]:50234 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751743AbcGOQRI (ORCPT ); Fri, 15 Jul 2016 12:17:08 -0400 Date: Fri, 15 Jul 2016 17:16:54 +0100 From: Mark Rutland To: Sebastian Andrzej Siewior Cc: Anna-Maria Gleixner , LKML , Peter Zijlstra , Ingo Molnar , Thomas Gleixner , rt@linutronix.de, Linus Torvalds , Will Deacon Subject: Re: [patch V2 35/67] arm/perf: Convert to hotplug state machine Message-ID: <20160715161654.GF19840@leverpostej> References: <20160713153219.128052238@linutronix.de> <20160713153335.794097159@linutronix.de> <20160715130818.GA19840@leverpostej> <20160715152629.GB16938@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160715152629.GB16938@linutronix.de> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 15, 2016 at 05:26:30PM +0200, Sebastian Andrzej Siewior wrote: > * Mark Rutland | 2016-07-15 14:08:18 [+0100]: > > >Hi, > Hi Mark, > > >We may have multiple PMUs (e.g. two in big.LITTLE systems), and > >__oprofile_cpu_pmu only contains one of these. So this conversion is not > >correct. > > > >We were relying on the notifier list implicitly containing a list of > >those PMUs. It seems like we need an explicit list here. > > > >We keep __oprofile_cpu_pmu around for legacy 32-bit users of OProfile > >(on non-hetereogeneous systems), and that's all that the variable should > >be used for. > > By the time I'e been looking there was only one node in the .dts. Now > you say it is not only possible but likely to have more than one node. Yes. For example, arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts is a big.LITTLE system with a Cortex-A7 PMU and a Cortex-A15 PMU. > So what we need is a list which gets extended in cpu_pmu_init() instead > of using the global pointer we have now. Correct? Yes, that sounds right to me, with matching removal in cpu_pmu_destroy. Thanks, Mark.