public inbox for linux-riscv@lists.infradead.org
 help / color / mirror / Atom feed
From: cp0613@linux.alibaba.com
To: atish.patra@linux.dev
Cc: anup@brainfault.org, alex@ghiti.fr, pjw@kernel.org,
	guoren@kernel.org, linux-riscv@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers/perf: riscv: Keep the fixed counter counting
Date: Mon,  9 Feb 2026 20:36:28 +0800	[thread overview]
Message-ID: <20260209123628.1866-1-cp0613@linux.alibaba.com> (raw)
In-Reply-To: <aab19ab9-0946-4477-8ca2-bc93621a54a0@linux.dev>

On Wed, 4 Feb 2026 01:17:25 -0800, atish.patra@linux.dev wrote:

> > 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.

Hi Atish,

Thanks for the reminder, but I might not be able to provide specific scenarios
due to our niche usage. Therefore, let's just discuss the legacy usage of
sysctl_perf_user_access.

> > 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 <cp0613@linux.alibaba.com>
> > ---
> >   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);

I have a slightly different understanding here. Regarding perf_user_access, I think
it is only used to control user mode access permissions to CYCLE, TIME, and INSTRET
(via SCOUNTEREN), but whether the counters themselves are in a counting state is
another issue (via MCOUNTINHIBIT). I think the cmask in pmu_sbi_stop_all should
represent a counter to stop the counting, rather than a permission configuration.

The problem we are currently encountering is that even when switching to LEGACY mode,
CYCLE and INSTRET are not counting, so we want to change this default behavior so
that these three fixed counters are always in counting.

Sorry for the late reply. I've reviewed some previous related discussions, and it
seems that using time is more reasonable between cycle and time. However, for some
small code snippets, there is a need to use cycle and instant (at least instant),
so keeping them constantly counting doesn't seem to have any downsides.

Thanks,
Pei

> >    /*
> >     * 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

  parent reply	other threads:[~2026-02-09 12:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-31 11:24 [PATCH] drivers/perf: riscv: Keep the fixed counter counting cp0613
2026-02-04  9:17 ` Atish Patra
2026-02-04 13:13   ` qingwei hu
2026-02-08  9:32     ` Atish Patra
2026-02-09 11:16       ` [External] " Qingwei Hu
2026-02-09 12:36   ` cp0613 [this message]
2026-03-28  3:57     ` Atish Patra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260209123628.1866-1-cp0613@linux.alibaba.com \
    --to=cp0613@linux.alibaba.com \
    --cc=alex@ghiti.fr \
    --cc=anup@brainfault.org \
    --cc=atish.patra@linux.dev \
    --cc=guoren@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=pjw@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox