All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Ian Rogers <irogers@google.com>,
	weilin.wang@intel.com, Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Ze Gao <zegao2021@gmail.com>, Leo Yan <leo.yan@linux.dev>,
	Ravi Bangoria <ravi.bangoria@amd.com>,
	Dmitrii Dolgov <9erthalion6@gmail.com>,
	Song Liu <song@kernel.org>, James Clark <james.clark@arm.com>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v1 0/3] Retirement latency perf stat support
Date: Fri, 26 Apr 2024 13:22:05 -0400	[thread overview]
Message-ID: <53dfaeae-b4eb-479e-938f-d0022c4f2416@linux.intel.com> (raw)
In-Reply-To: <20240425223406.471120-1-irogers@google.com>



On 2024-04-25 6:34 p.m., Ian Rogers wrote:
> Support 'R' as a retirement latency modifier on events. When present
> the evsel will fork perf record and perf report commands, parsing the
> perf report output as the count value. The intent is to do something
> similar to Weilin's series:
> https://lore.kernel.org/lkml/20240402214436.1409476-1-weilin.wang@intel.com/
> 
> While the 'R' and the retirement latency are Intel specific, in the
> future I can imagine more evsel like commands that require child
> processes. We can make the logic more generic at that point.
>

I think in generic what we want is the weight/latency information of the
event. 'W' is already occupied by the weak group. Maybe 'L' is a more
generic name than 'R'. With the event modifier, perf collects and report
the weight/latency information of the event in a perf stat command.

Not just changing the evsel, I think a proper output is still required.
It's possible that an end user can use it without metrics. E.g.,
perf stat -e cycles,instructions:L
A possible generic output maybe

1,931,099,931	cycles
  801,826,458	instructions	# Avg Weight1 1000
				# Avg Weight2 800
				# Avg Weight3 500

Thanks,
Kan

> The code is untested on hardware that supports retirement latency, and
> with metrics with retirement latency in them. The record is also of
> sleep and various things need tweaking but I think v1 is good enough
> for people to give input.
> 
> The first patch stops opening a dummy event for tool events. I came
> across this while looking into the issue and we can likely just pick
> it first. I kept it in the series for cleanliness sake.
> 
> The code has benefitted greatly from Weilin's work and Namhyung's
> great review input.
> 
> Ian Rogers (3):
>   perf evsel: Don't open tool events
>   perf parse-events: Add a retirement latency modifier
>   perf evsel: Add retirement latency event support
> 
>  tools/perf/util/evsel.c        | 186 ++++++++++++++++++++++++++++++++-
>  tools/perf/util/evsel.h        |   4 +
>  tools/perf/util/parse-events.c |   2 +
>  tools/perf/util/parse-events.h |   1 +
>  tools/perf/util/parse-events.l |   3 +-
>  5 files changed, 192 insertions(+), 4 deletions(-)
> 

  parent reply	other threads:[~2024-04-26 17:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-25 22:34 [RFC PATCH v1 0/3] Retirement latency perf stat support Ian Rogers
2024-04-25 22:34 ` [RFC PATCH v1 1/3] perf evsel: Don't open tool events Ian Rogers
2024-04-25 22:34 ` [RFC PATCH v1 2/3] perf parse-events: Add a retirement latency modifier Ian Rogers
2024-04-25 22:34 ` [RFC PATCH v1 3/3] perf evsel: Add retirement latency event support Ian Rogers
2024-04-25 22:41 ` [RFC PATCH v1 0/3] Retirement latency perf stat support Ian Rogers
2024-04-26 17:22 ` Liang, Kan [this message]
2024-04-26 17:34   ` Ian Rogers

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=53dfaeae-b4eb-479e-938f-d0022c4f2416@linux.intel.com \
    --to=kan.liang@linux.intel.com \
    --cc=9erthalion6@gmail.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=irogers@google.com \
    --cc=james.clark@arm.com \
    --cc=jolsa@kernel.org \
    --cc=leo.yan@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=ravi.bangoria@amd.com \
    --cc=song@kernel.org \
    --cc=weilin.wang@intel.com \
    --cc=zegao2021@gmail.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.