From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 75A34C531DC for ; Fri, 16 Aug 2024 10:26:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=OQzGHzl0e7jazRRg0nQyGkFd+g8miZqKmauW9Z/Csyo=; b=mQRLfOemrnme6n5Nye1lP/1vuu ovdglQJ9KtexapEC7jpEvNI/rsYQ5pH5H1FIgoaY9CpOvu5hTGZe3HtsDQTVtput4nJOJwzBhCsFs zzlTkP/9+5SHVoOREGB6Db1fm+lnKMlshEDwDUEEsGlv0z18vQS38c+RYbyTRJyYzOXSYmIHSCapV ArfzNgB8osrgHAIR7u+jpWxV4AqbLr9V2dw+vT0j3KQ4av9uOeGMB/lkXj75uWca6VqyeZ3nCJzH0 PlU+rbHYqIM7uVTuuGFkSPMjbrsMA3QlxSBKcdHl6JAz2fttcYAEHiTbmArXeExNKbeMW9Nq3SKWV 5VxAd9IA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1seu9t-0000000CaTU-1wy1; Fri, 16 Aug 2024 10:26:13 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1seu9E-0000000CaPD-2qx2 for linux-arm-kernel@lists.infradead.org; Fri, 16 Aug 2024 10:25:34 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9B1AC143D; Fri, 16 Aug 2024 03:25:57 -0700 (PDT) Received: from J2N7QTR9R3 (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B71FE3F73B; Fri, 16 Aug 2024 03:25:30 -0700 (PDT) Date: Fri, 16 Aug 2024 11:25:28 +0100 From: Mark Rutland To: Robin Murphy Cc: will@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, ilkka@os.amperecomputing.com Subject: Re: [PATCH 5/8] perf/arm-cmn: Make cycle counts less surprising Message-ID: References: <570c473134426b8e11bb043aa59e3cde3dab8af3.1723229941.git.robin.murphy@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <570c473134426b8e11bb043aa59e3cde3dab8af3.1723229941.git.robin.murphy@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240816_032532_829054_C973B135 X-CRM114-Status: GOOD ( 25.32 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Aug 09, 2024 at 08:15:44PM +0100, Robin Murphy wrote: > By default, CMN has automatic clock-gating with the implication that a > DTC's cycle counter may not increment while the domain is sufficiently > idle. Similar is true for the cycles event on the CPU side, so this has some precedent. > Given that we may have up to 4 DTCs to choose from when scheduling > a cycles event, this may potentially lead to surprising results if > trying to measure metrics based on activity in a different DTC domain > from where cycles end up being counted. Make the reasonable assumption > that if the user wants to count cycles, they almost certainly want to > count all of the cycles, and disable clock gating while a DTC's cycle > counter is in use. As above, the default does match the CPU side behaviour, and a user might be trying to determine how much clock gating occurs over some period, so it's not necessarily right to always disable clock gating. That might need to be an explicit option on the cycles event. Do we always have the ability to disable clock gating, or can that be locked down by system integration or FW? Mark. > > Signed-off-by: Robin Murphy > --- > drivers/perf/arm-cmn.c | 16 +++++++++++----- > 1 file changed, 11 insertions(+), 5 deletions(-) > > diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c > index 8f7a1a6f8ab7..4d128db2040c 100644 > --- a/drivers/perf/arm-cmn.c > +++ b/drivers/perf/arm-cmn.c > @@ -115,6 +115,7 @@ > /* The DTC node is where the magic happens */ > #define CMN_DT_DTC_CTL 0x0a00 > #define CMN_DT_DTC_CTL_DT_EN BIT(0) > +#define CMN_DT_DTC_CTL_CG_DISABLE BIT(10) > > /* DTC counters are paired in 64-bit registers on a 16-byte stride. Yuck */ > #define _CMN_DT_CNT_REG(n) ((((n) / 2) * 4 + (n) % 2) * 4) > @@ -1544,9 +1545,12 @@ static void arm_cmn_event_start(struct perf_event *event, int flags) > int i; > > if (type == CMN_TYPE_DTC) { > - i = hw->dtc_idx[0]; > - writeq_relaxed(CMN_CC_INIT, cmn->dtc[i].base + CMN_DT_PMCCNTR); > - cmn->dtc[i].cc_active = true; > + struct arm_cmn_dtc *dtc = cmn->dtc + hw->dtc_idx[0]; > + > + writel_relaxed(CMN_DT_DTC_CTL_DT_EN | CMN_DT_DTC_CTL_CG_DISABLE, > + dtc->base + CMN_DT_DTC_CTL); > + writeq_relaxed(CMN_CC_INIT, dtc->base + CMN_DT_PMCCNTR); > + dtc->cc_active = true; > } else if (type == CMN_TYPE_WP) { > u64 val = CMN_EVENT_WP_VAL(event); > u64 mask = CMN_EVENT_WP_MASK(event); > @@ -1575,8 +1579,10 @@ static void arm_cmn_event_stop(struct perf_event *event, int flags) > int i; > > if (type == CMN_TYPE_DTC) { > - i = hw->dtc_idx[0]; > - cmn->dtc[i].cc_active = false; > + struct arm_cmn_dtc *dtc = cmn->dtc + hw->dtc_idx[0]; > + > + dtc->cc_active = false; > + writel_relaxed(CMN_DT_DTC_CTL_DT_EN, dtc->base + CMN_DT_DTC_CTL); > } else if (type == CMN_TYPE_WP) { > for_each_hw_dn(hw, dn, i) { > void __iomem *base = dn->pmu_base + CMN_DTM_OFFSET(hw->dtm_offset); > -- > 2.39.2.101.g768bb238c484.dirty >