From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Richter Subject: Re: [PATCH V3 0/6] Generalise ARM perf-events backend for oprofile Date: Thu, 16 Sep 2010 16:48:28 +0200 Message-ID: <20100916144828.GD13563@erda.amd.com> References: <1284372533.3042.11.camel@e102144-lin.cambridge.arm.com> <20100913111850.GC14882@console-pimps.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Return-path: Content-Disposition: inline In-Reply-To: <20100913111850.GC14882@console-pimps.org> Sender: linux-sh-owner@vger.kernel.org To: Matt Fleming Cc: Will Deacon , Paul Mundt , Russell King , "linux-arm-kernel@lists.infradead.org" , "linux-sh@vger.kernel.org" , Peter Zijlstra , Ingo Molnar , Frederic Weisbecker , Arnaldo Carvalho de Melo , "linux-arch@vger.kernel.org" List-Id: linux-arch.vger.kernel.org On 13.09.10 07:18:50, Matt Fleming wrote: > On Mon, Sep 13, 2010 at 11:08:53AM +0100, Will Deacon wrote: > > I've tested this patch series on a multicore Cortex-A9 board. If I > > revert patch 5/6 (ARM: Make oprofile depend on CONFIG_HW_PERF_EVENTS) > > then everything seems to work fine. Otherwise, testing without > > HW_PERF_EVENTS doesn't fall back to timer mode. > > > > So, with the exception of the patch above: > > > > Tested-by: Will Deacon > > Hi Will, thanks for testing! > > Ah yeah, making oprofile rely on CONFIG_HW_PERF_EVENTS is too > strict. I hadn't noticed that armpmu_get_pmu_id() is wrapped in > CONFIG_HW_PERF_EVENTS and had intended op->cpu_type to be NULL and so > we'd fallback to the timer mode. > > This patch needs to be dropped entirely (though another patch should > conditionally include oprofile_perf.o based on CONFIG_HW_PERF_EVENT > like I had in my original series). Matt, yes, the patch set looks good so far. With the exception of some minor comments I made and patch #5 dropped, we should be fine. Please update the patches. Thanks, -Robert -- Advanced Micro Devices, Inc. Operating System Research Center From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from va3ehsobe001.messaging.microsoft.com ([216.32.180.11]:57041 "EHLO VA3EHSOBE001.bigfish.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755085Ab0IPOtJ (ORCPT ); Thu, 16 Sep 2010 10:49:09 -0400 Date: Thu, 16 Sep 2010 16:48:28 +0200 From: Robert Richter Subject: Re: [PATCH V3 0/6] Generalise ARM perf-events backend for oprofile Message-ID: <20100916144828.GD13563@erda.amd.com> References: <1284372533.3042.11.camel@e102144-lin.cambridge.arm.com> <20100913111850.GC14882@console-pimps.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20100913111850.GC14882@console-pimps.org> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Matt Fleming Cc: Will Deacon , Paul Mundt , Russell King , "linux-arm-kernel@lists.infradead.org" , "linux-sh@vger.kernel.org" , Peter Zijlstra , Ingo Molnar , Frederic Weisbecker , Arnaldo Carvalho de Melo , "linux-arch@vger.kernel.org" Message-ID: <20100916144828.u5yVxPqXdEDAzklu_dfyXm8guGmY2u4bqTBc4h_bdDE@z> On 13.09.10 07:18:50, Matt Fleming wrote: > On Mon, Sep 13, 2010 at 11:08:53AM +0100, Will Deacon wrote: > > I've tested this patch series on a multicore Cortex-A9 board. If I > > revert patch 5/6 (ARM: Make oprofile depend on CONFIG_HW_PERF_EVENTS) > > then everything seems to work fine. Otherwise, testing without > > HW_PERF_EVENTS doesn't fall back to timer mode. > > > > So, with the exception of the patch above: > > > > Tested-by: Will Deacon > > Hi Will, thanks for testing! > > Ah yeah, making oprofile rely on CONFIG_HW_PERF_EVENTS is too > strict. I hadn't noticed that armpmu_get_pmu_id() is wrapped in > CONFIG_HW_PERF_EVENTS and had intended op->cpu_type to be NULL and so > we'd fallback to the timer mode. > > This patch needs to be dropped entirely (though another patch should > conditionally include oprofile_perf.o based on CONFIG_HW_PERF_EVENT > like I had in my original series). Matt, yes, the patch set looks good so far. With the exception of some minor comments I made and patch #5 dropped, we should be fine. Please update the patches. Thanks, -Robert -- Advanced Micro Devices, Inc. Operating System Research Center