From: Ingo Molnar <mingo@kernel.org>
To: "Liang, Kan" <kan.liang@linux.intel.com>
Cc: Luo Gengkun <luogengkun@huaweicloud.com>,
peterz@infradead.org, mingo@redhat.com, acme@kernel.org,
namhyung@kernel.org, mark.rutland@arm.com,
alexander.shishkin@linux.intel.com, jolsa@kernel.org,
irogers@google.com, adrian.hunter@intel.com, tglx@linutronix.de,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, ravi.bangoria@amd.com,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] perf/x86: Fix open counting event error
Date: Thu, 24 Apr 2025 20:14:49 +0200 [thread overview]
Message-ID: <aAp_mQadre6-aFg8@gmail.com> (raw)
In-Reply-To: <e85c1a65-fa55-457f-82d9-c25f6a4deb49@linux.intel.com>
* Liang, Kan <kan.liang@linux.intel.com> wrote:
>
>
> On 2025-04-24 12:20 p.m., Ingo Molnar wrote:
> >
> > * Luo Gengkun <luogengkun@huaweicloud.com> wrote:
> >
> >> Perf doesn't work at perf stat for hardware events:
> >>
> >> $perf stat -- sleep 1
> >> Performance counter stats for 'sleep 1':
> >> 16.44 msec task-clock # 0.016 CPUs utilized
> >> 2 context-switches # 121.691 /sec
> >> 0 cpu-migrations # 0.000 /sec
> >> 54 page-faults # 3.286 K/sec
> >> <not supported> cycles
> >> <not supported> instructions
> >> <not supported> branches
> >> <not supported> branch-misses
> >>
> >> The reason is that the check in x86_pmu_hw_config for sampling event is
> >> unexpectedly applied to the counting event.
> >>
> >> Fixes: 88ec7eedbbd2 ("perf/x86: Fix low freqency setting issue")
> >> Signed-off-by: Luo Gengkun <luogengkun@huaweicloud.com>
> >> ---
> >> arch/x86/events/core.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> >> index 6866cc5acb0b..3a4f031d2f44 100644
> >> --- a/arch/x86/events/core.c
> >> +++ b/arch/x86/events/core.c
> >> @@ -629,7 +629,7 @@ int x86_pmu_hw_config(struct perf_event *event)
> >> if (event->attr.type == event->pmu->type)
> >> event->hw.config |= x86_pmu_get_event_config(event);
> >>
> >> - if (!event->attr.freq && x86_pmu.limit_period) {
> >> + if (is_sampling_event(event) && !event->attr.freq && x86_pmu.limit_period) {
> >
> > Hm, so how come it works here, on an affected x86 system:
> >
> > $ perf stat -- sleep 1
> >
> > Performance counter stats for 'sleep 1':
> >
> > 0.64 msec task-clock:u # 0.001 CPUs utilized
> > 0 context-switches:u # 0.000 /sec
> > 0 cpu-migrations:u # 0.000 /sec
> > 73 page-faults:u # 114.063 K/sec
> > 325,849 instructions:u # 0.56 insn per cycle
> > # 0.88 stalled cycles per insn
> > 580,323 cycles:u # 0.907 GHz
> > 286,348 stalled-cycles-frontend:u # 49.34% frontend cycles idle
> > 72,623 branches:u # 113.474 M/sec
> > 4,713 branch-misses:u # 6.49% of all branches
> >
> >
> > ?
>
> It doesn't affect all X86 platforms. It should only impact the platforms
> with limit_period used for the non-pebs events. For Intel platforms, it
> should only impact some older platforms, e.g., HSW, BDW and NHM.
>
> For other platforms, the x86_pmu.limit_period is invoked. But the left
> is not updated. So it still equals to event->attr.sample_period.
> It doesn't error out.
>
> if (!event->attr.freq && x86_pmu.limit_period) {
> s64 left = event->attr.sample_period;
> x86_pmu.limit_period(event, &left);
> if (left > event->attr.sample_period)
> return -EINVAL;
> }
Makes sense. I've added this paragraph to the changelog:
It should only impact x86 platforms with limit_period used for non-PEBS
events. For Intel platforms, it should only impact some older platforms,
e.g., HSW, BDW and NHM.
Thanks,
Ingo
next prev parent reply other threads:[~2025-04-24 18:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-23 6:47 [PATCH] perf/x86: Fix open counting event error Luo Gengkun
2025-04-23 13:51 ` Liang, Kan
2025-04-24 6:52 ` Ravi Bangoria
2025-04-24 17:15 ` Liang, Kan
2025-04-25 10:12 ` Ravi Bangoria
2025-04-30 14:12 ` Liang, Kan
2025-04-24 16:20 ` Ingo Molnar
2025-04-24 17:08 ` Liang, Kan
2025-04-24 18:14 ` Ingo Molnar [this message]
2025-04-24 18:22 ` [tip: perf/urgent] perf/x86: Fix non-sampling (counting) events on certain x86 platforms tip-bot2 for Luo Gengkun
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=aAp_mQadre6-aFg8@gmail.com \
--to=mingo@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=luogengkun@huaweicloud.com \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=ravi.bangoria@amd.com \
--cc=tglx@linutronix.de \
--cc=x86@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.