All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.