All of lore.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: Zide Chen <zide.chen@intel.com>
Cc: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Ingo Molnar <mingo@redhat.com>, Jiri Olsa <jolsa@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	thomas.falcon@intel.com, dapeng1.mi@linux.intel.com,
	xudong.hao@intel.com
Subject: Re: [PATCH] perf tools: Refactor precise_ip fallback logic
Date: Thu, 23 Oct 2025 19:30:14 -0700	[thread overview]
Message-ID: <aPrktlANBHFtV52B@google.com> (raw)
In-Reply-To: <20251022220802.1335131-1-zide.chen@intel.com>

Hello,

On Wed, Oct 22, 2025 at 03:08:02PM -0700, Zide Chen wrote:
> Commit c33aea446bf555ab ("perf tools: Fix precise_ip fallback logic")
> unconditionally called the precise_ip fallback and moved it after the
> missing-feature checks so that it could handle EINVAL as well.
> 
> However, this introduced an issue: after disabling missing features,
> the event could fail to open, which makes the subsequent precise_ip
> fallback useless since it will always fail.
> 
> For example, run the following command on Intel SPR:
> 
> $ perf record -e '{cpu/mem-loads-aux/S,cpu/mem-loads,ldlat=3/PS}' -- ls
> 
> Opening the event "cpu/mem-loads,ldlat=3/PS" returns EINVAL when
> precise_ip == 3. It then sets attr.inherit = false, which triggers a

I'm curious about this part.  Why the kernel set 'inherit = false'?  IOW
how did the leader event (mem-loads-aux) succeed with inherit = true
then?

> kernel check failure since it doesn't match the group leader's inherit
> attribute. As a result, it continues to fail even after precise_ip is
> reduced.
> 
> By moving the precise_ip fallback earlier, this issue is resolved, as
> well as the kernel test robot report mentioned in commit
> c33aea446bf555ab.
> 
> No negative side effects are expected, because the precise_ip level is
> restored by evsel__precise_ip_fallback() if the fallback does not help.

I'm not sure.. some events may need a different (i.e. lower) precise
level than the max.  I think checking the missing feature later will
use the max precise level always.

Thanks,
Namhyung

> 
> This also aligns with commit 2b70702917337a8d ("perf tools: Remove
> evsel__handle_error_quirks()").
> 
> Fixes: af954f76eea56453 ("perf tools: Check fallback error and order")
> Fixes: c33aea446bf555ab ("perf tools: Fix precise_ip fallback logic")
> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
> Signed-off-by: Zide Chen <zide.chen@intel.com>
> ---
>  tools/perf/util/evsel.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> index ca74514c8707..6ce32533a213 100644
> --- a/tools/perf/util/evsel.c
> +++ b/tools/perf/util/evsel.c
> @@ -2714,12 +2714,12 @@ static int evsel__open_cpu(struct evsel *evsel, struct perf_cpu_map *cpus,
>  	if (err == -EMFILE && rlimit__increase_nofile(&set_rlimit))
>  		goto retry_open;
>  
> +	if (evsel__precise_ip_fallback(evsel))
> +		goto retry_open;
> +
>  	if (err == -EINVAL && evsel__detect_missing_features(evsel, cpu))
>  		goto fallback_missing_features;
>  
> -	if (evsel__precise_ip_fallback(evsel))
> -		goto retry_open;
> -
>  out_close:
>  	if (err)
>  		threads->err_thread = thread;
> -- 
> 2.51.0
> 

  parent reply	other threads:[~2025-10-24  2:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-22 22:08 [PATCH] perf tools: Refactor precise_ip fallback logic Zide Chen
2025-10-23 16:14 ` Ian Rogers
2025-10-23 22:11   ` Chen, Zide
2026-02-06 22:06   ` Arnaldo Carvalho de Melo
2026-02-06 22:10     ` Arnaldo Carvalho de Melo
2025-10-24  2:30 ` Namhyung Kim [this message]
2025-10-24 18:03   ` Chen, Zide
2025-10-26  0:42     ` Namhyung Kim
2025-10-27 18:56       ` Chen, Zide
2025-11-04  3:48         ` Namhyung Kim
2025-11-04 19:10           ` Chen, Zide
2025-11-06 18:52             ` Namhyung Kim
2025-11-07  1:23               ` Chen, Zide
2025-11-07 21:42                 ` Namhyung Kim
2025-11-07 22:31                   ` Chen, Zide
2025-11-11  7:50                     ` Namhyung Kim
2025-11-11 19:11                       ` Chen, Zide
2025-11-11 19:34                         ` Namhyung Kim
2025-11-11 20:01                           ` Chen, Zide

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=aPrktlANBHFtV52B@google.com \
    --to=namhyung@kernel.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=dapeng1.mi@linux.intel.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=thomas.falcon@intel.com \
    --cc=xudong.hao@intel.com \
    --cc=zide.chen@intel.com \
    /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.