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 6303FC2BA18 for ; Tue, 18 Jun 2024 16:30:55 +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:Content-Transfer-Encoding: Content-Type:In-Reply-To:References:Cc:To:From:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=3xiubAJxD42gEmQC+ny2kux59Uo2fhGpaG4PExyPXbU=; b=zHb+BJ3g/WrEDy8Gg7zsPiLMMY gNNBUdjoLQUNYSdNiFm6n5dCG1ah7+vscHdWRbBXdLM6Vg1oktpqAZ8IBdHiQWEHA2qWgOYKOxhWL dayG+KW5FyAc3WUBolK0CHz4sZ5zghNVpWn0wqp6LzhIInplIvHYveZD1bNosCgBf1z2C+IEEb9N7 J2kQCzwpaWTD4gzNSq8VXMr3sTCn70K7DJz/L1V0zEpbTo+n3ZyqMn2PVsvIrIMiRAc7cBEHIAJcF 0mD3txqv71D6idmtM/WeBpfKlxzRNOUj9ouuBayGuOEoXmXzbiKV8hsETAZxGt6Qgy7+sH+w5wpAI KLVQpU2g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sJbjH-0000000FrhL-3UxO; Tue, 18 Jun 2024 16:30:43 +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 1sJbjE-0000000Frfl-3Qss for linux-arm-kernel@lists.infradead.org; Tue, 18 Jun 2024 16:30:42 +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 C7787DA7; Tue, 18 Jun 2024 09:31:01 -0700 (PDT) Received: from [10.57.41.41] (unknown [10.57.41.41]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 46DB23F6A8; Tue, 18 Jun 2024 09:30:36 -0700 (PDT) Message-ID: <8804f769-faa2-4d88-8196-8f1ed62d076c@arm.com> Date: Tue, 18 Jun 2024 17:30:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] perf: arm_pmuv3: Avoid assigning fixed cycle counter with threshold From: James Clark To: "Rob Herring (Arm)" Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Will Deacon , Mark Rutland References: <20240611155012.2286044-1-robh@kernel.org> <8c55de88-96ad-45a7-9be5-4f33f4266af2@arm.com> Content-Language: en-US In-Reply-To: <8c55de88-96ad-45a7-9be5-4f33f4266af2@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240618_093040_960182_DE3F128B X-CRM114-Status: GOOD ( 20.29 ) 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 11/06/2024 17:13, James Clark wrote: > > > On 11/06/2024 16:50, Rob Herring (Arm) wrote: >> If the user has requested a counting threshold for the CPU cycles event, >> then the fixed cycle counter can't be assigned as it lacks threshold >> support. Currently, the thresholds will work or not randomly depending >> on which counter the event is assigned. >> >> While using thresholds for CPU cycles doesn't make much sense, it can be >> useful for testing purposes. >> >> Fixes: 816c26754447 ("arm64: perf: Add support for event counting threshold") >> Signed-off-by: Rob Herring (Arm) >> --- >> drivers/perf/arm_pmuv3.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/perf/arm_pmuv3.c b/drivers/perf/arm_pmuv3.c >> index 23fa6c5da82c..2612be29ee23 100644 >> --- a/drivers/perf/arm_pmuv3.c >> +++ b/drivers/perf/arm_pmuv3.c >> @@ -939,9 +939,10 @@ static int armv8pmu_get_event_idx(struct pmu_hw_events *cpuc, >> struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu); >> struct hw_perf_event *hwc = &event->hw; >> unsigned long evtype = hwc->config_base & ARMV8_PMU_EVTYPE_EVENT; >> + bool has_threshold = !!(hwc->config_base & ARMV8_PMU_EVTYPE_TH); > > I was going to say doesn't it need to be (ARMV8_PMU_EVTYPE_TH | > ARMV8_PMU_EVTYPE_TC) for it to give the same results as the hardware. > But then I saw we only enable it if TH != 0, even if TC is set. And now > I'm wondering if I inadvertently disabled a useful combination of options. > > The Arm ARM says it's only completely disabled when both TC and TH are 0. > If it's easy it might be worth adding a helper function for has_threshold() that's used in both places. That way if or when this issue gets fixed up it doesn't break here. >> >> /* Always prefer to place a cycle counter into the cycle counter. */ >> - if (evtype == ARMV8_PMUV3_PERFCTR_CPU_CYCLES) { >> + if ((evtype == ARMV8_PMUV3_PERFCTR_CPU_CYCLES) && !has_threshold) { >> if (!test_and_set_bit(ARMV8_IDX_CYCLE_COUNTER, cpuc->used_mask)) >> return ARMV8_IDX_CYCLE_COUNTER; >> else if (armv8pmu_event_is_64bit(event) &&