From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752852Ab2BTJou (ORCPT ); Mon, 20 Feb 2012 04:44:50 -0500 Received: from cam-admin0.cambridge.arm.com ([217.140.96.50]:46429 "EHLO cam-admin0.cambridge.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751995Ab2BTJot (ORCPT ); Mon, 20 Feb 2012 04:44:49 -0500 Date: Mon, 20 Feb 2012 09:44:14 +0000 From: Will Deacon To: Ming Lei Cc: Peter Zijlstra , "eranian@gmail.com" , "Shilimkar, Santosh" , David Long , "b-cousson@ti.com" , "mans@mansr.com" , linux-arm , Ingo Molnar , Linux Kernel Mailing List Subject: Re: oprofile and ARM A9 hardware counter Message-ID: <20120220094414.GA13115@mudshark.cambridge.arm.com> References: <1329323900.2293.150.camel@twins> <20120216150004.GE2641@mudshark.cambridge.arm.com> <1329409183.2293.245.camel@twins> <20120216180841.GC31977@mudshark.cambridge.arm.com> <20120217102643.GA17909@mudshark.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Mon, Feb 20, 2012 at 03:19:02AM +0000, Ming Lei wrote: > On Fri, Feb 17, 2012 at 6:26 PM, Will Deacon wrote: > > Not sure I follow. If the frequency is 10000, then we write 0xffffd8f0 to > > the counter. That means we have a 0xffffd8f0 event window to read the > > The frequency I described is the 'freq' from '-F freq'. On OMAP4, when > the 'freq' > is 10000 and the interval for one samle is 100us, the observed counter > ('left' variable in armpmu_event_set_period) is about 90000, so the written > value to the hw counter is 0xFFFEA06F, looks the window is wide enough, > and we may not consider the issue in a737823d for sample-based profiling. My mistake - I thought you were referring to a period of 10000, but similar logic follows. > > There's a trade off between allowing the counter to wrap back around past > > its previous value or being able to handle overflow on a non-interrupt path. > > I agree, it is not easy to read overflow flag and counter accurately > from hardware > directly on a non-interrupt path. > > So do you need me to prepare a new patch, or you will do it by yourself? If the last one I posted is alright to you (seems that it is), then I'll update it with the removal of the overflow flag and post it to the list with you on CC. I also need to get to the bottom of those warnings. Thanks, Will