From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-189.mta0.migadu.com (out-189.mta0.migadu.com [91.218.175.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CFEFA29C321 for ; Sun, 8 Feb 2026 09:32:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.189 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770543133; cv=none; b=A7r7U4S2h8hky6eDduQgNIYITuHxJoPHB2xWOMkZPq6BhfThcU51/OyTvl/cxip3Rtx9Ye2XWiNl7tkeqcuuSiHBPbryGcUNEG/0AZffnkkDpnkJX+X53NPIUzPRwORKpstCqJ3dfNB7SggL5nawbbxGsBX+9pkm75ll63QkZOE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770543133; c=relaxed/simple; bh=9qz6k/tG1WsUWCVVktAG5rrwpmAWLCErYhSj1s7wrvo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=uEkBEzcBWblh4C4tLXzC8oaQfFpb+TUVU5L1hFV4JuM6b//MHVoCwsDghggwwyptY5F7BDZ8ZD994F6Mioq2lALLe5X3koVeOUlHca0WxewWd9llchleBZRjZUs0UA7t+TqhmTO2lCLQbZtF124ceOcGJl4Chpvlbqh4p5DwHE0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=nxafQ58s; arc=none smtp.client-ip=91.218.175.189 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="nxafQ58s" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1770543130; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1CWhrmyvp8UhILa66Gxm7tpIQjK5QG/i9orbqL8doRk=; b=nxafQ58sCCuEIytdobpH10lnLTdLcUlboS9wCoPJ8kf02MBcLcPMi0zl8FPCOV7Cw6u/uF gsNUizTfwdcbimsblyD/6d5lgBuUVI13YKDmuO9cRMEiZHWDssJydwbblGdjx/s4mjnXry 4p5eaQGzFCH1+F37mSh4zw7Mqr4dYTc= Date: Sun, 8 Feb 2026 01:32:02 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH] drivers/perf: riscv: Keep the fixed counter counting To: qingwei hu Cc: cp0613@linux.alibaba.com, anup@brainfault.org, alex@ghiti.fr, pjw@kernel.org, guoren@kernel.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org References: <20260131112440.2915-1-cp0613@linux.alibaba.com> <0E982A8E-9CD2-4712-AC59-56D7CA043A2A@bytedance.com> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Atish Patra In-Reply-To: <0E982A8E-9CD2-4712-AC59-56D7CA043A2A@bytedance.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 2/4/26 5:13 AM, qingwei hu wrote: >> On Feb 4, 2026, at 17:17, Atish Patra wrote: >> >> >> On 1/31/26 3:24 AM, cp0613@linux.alibaba.com wrote: >>> From: Chen Pei >>> >>> The RISC-V SBI PMU driver disables all PMU counters during initialization >>> via pmu_sbi_stop_all. For fixed counters CYCLE, TIME and INSTRET, this is >>> unnecessary for the following two reasons: >>> >>> 1. Some kernel driver code may directly read CYCLE and INSTRET to perform >>> simple performance analysis. >> Is this for some debugging purpose to read the instret/cycle count at boot time or real use case for driver performance analysis ? >> >> If it is the latter, that will be problematic for various reasons such as context switching will lead to inaccurate numbers. > Hello Atish. > > Besides boot time scenarios and performance analysis, there is another case > where user mode needs to access the cycle counter via rdcycle. > >>> 2. In legacy mode, user space directly reads CYCLE and INSTRET. (echo 2 > >>> /proc/sys/kernel/perf_user_access) >>> >>> Therefore, We keep counting CYCLE, TIME and INSTRET. >>> >>> Signed-off-by: Chen Pei >>> --- >>> drivers/perf/riscv_pmu_sbi.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c >>> index 7dd282da67ce..93aaab324443 100644 >>> --- a/drivers/perf/riscv_pmu_sbi.c >>> +++ b/drivers/perf/riscv_pmu_sbi.c >>> @@ -899,6 +899,9 @@ static int pmu_sbi_get_ctrinfo(int nctr, unsigned long *mask) >>> static inline void pmu_sbi_stop_all(struct riscv_pmu *pmu) >>> { >>> + /* We keep counting CYCLE, TIME and INSTRET. */ >>> + pmu->cmask &= ~0x7; >>> + >> This is incorrect. The cmask should be set based on the perf_user_access value. We should not continue counting the CYCLE/INSTRET when legacy mode is not set. if (sysctl_perf_user_access == SYSCTL_LEGACY) csr_write(CSR_SCOUNTEREN, 0x7); else csr_write(CSR_SCOUNTEREN, 0x2); > Legacy mode refers to the perf framework. When perf_user_access is not in > legacy mode, the application may need to use rdcycle. > > As discussed in [1], the rdcycle is necessary, and applications such as > DPDK should use rdcycle in user mode. > > So how to use the rdcycle when perf_user_access is not in legacy mode? > > [1] https://lists.riscv.org/g/tech-privileged/topic/should_rdcycle_be_deprecated/115162737 Based on this thread, it was very clear that the dpdk use case of rdcycle is incorrect. We also had many discussions why enabling rdcycle without perf is a bad idea. That's the reason why we added the *sysctl_perf_user_access* legacy to preserve legacy usage. Eventually, it is expected that folks would move away from rdcycle usage which was incorrect to begin with. Let me know if you want me dig up the old threads about the discussion. > Best Regards, > Qingwei Hu > >>> /* >>> * No need to check the error because we are disabling all the counters >>> * which may include counters that are not enabled yet. >> _______________________________________________ >> linux-riscv mailing list >> linux-riscv@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-riscv >