From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Ian Rogers <irogers@google.com>,
"Mi, Dapeng" <dapeng1.mi@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
Dapeng Mi <dapeng1.mi@intel.com>
Subject: Re: [PATCH] perf topdown: Correct leader selection with sample_read enabled
Date: Fri, 28 Jun 2024 16:27:37 -0400 [thread overview]
Message-ID: <350e5bf7-23ee-4a7f-8b62-e3d07604cbe1@linux.intel.com> (raw)
In-Reply-To: <CAP-5=fVYmUvYawOBtUc_-PVzsTQhpOuMx4wxA7bHjwaZejii8Q@mail.gmail.com>
On 2024-06-28 2:28 p.m., Ian Rogers wrote:
> On Thu, Jun 27, 2024 at 11:17 PM Mi, Dapeng <dapeng1.mi@linux.intel.com> wrote:
>> On 6/27/2024 11:11 PM, Liang, Kan wrote:
>>> On 2024-06-14 5:39 p.m., Dapeng Mi wrote:
>>>
>>> Besides, we need a test for the sampling read as well.
>>> Ian has provided a very good base. Please add a topdown sampling read
>>> case on top of it as well.
>>> https://lore.kernel.org/lkml/CAP-5=fUkg-cAXTb+3wbFOQCfdXgpQeZw40XHjfrNFbnBD=NMXg@mail.gmail.com/
>>
>> Sure. I would look at it and add a test case.
>
> Thanks Dapeng and thanks Kan too! I wonder if we can do a regular
> counter and a leader sample counter then compare the counts are
> reasonably consistent. Something like this:
>
> ```
> $ perf stat -e instructions perf test -w noploop
>
> Performance counter stats for '/tmp/perf/perf test -w noploop':
>
> 25,779,785,496 instructions
>
> 1.008047696 seconds time elapsed
>
> 1.003754000 seconds user
> 0.003999000 seconds sys
> ```
>
> ```
> cat << "_end_of_file_" > a.py
> last_count = None
>
> def process_event(param_dict):
> if ("ev_name" in param_dict and "sample" in param_dict and
> param_dict["ev_name"] == "instructions"):
> sample = param_dict["sample"]
> if "values" in sample:
> global last_count
> last_count = sample["values"][1][1]
>
> def trace_end():
> global last_count
> print(last_count)
> _end_of_file_
> $ sudo perf record -o - -e "{cycles,instructions}:S" perf test -w
> noploop|perf script -i - -s ./a.py
> [ perf record: Woken up 2 times to write data ]
> [ perf record: Captured and wrote 0.459 MB - ]
> 22195356100
> ```
>
> I didn't see a simpler way to get count and I don't think it is right.
The perf stat can cover the whole life cycle of a workload. But I think
the result of perf record can only give the sum from the beginning to
the last sample.
There are some differences.
> There's some similar perf script checking of data in
> tools/perf/tests/shell/test_intel_pt.sh.
>
I think the case should be to test the output of the perf script, rather
than verify the accuracy of an event.
If so, we may run two same events. They should show the exact same
results in a sample.
For example,
perf record -e "{branches,branches}:Su" -c 1000000 ./perf test -w brstack
perf script
perf 752598 349300.123884: 1000002 branches: 7f18676a875a
do_lookup_x+0x2fa (/usr/lib64/l>
perf 752598 349300.123884: 1000002 branches: 7f18676a875a
do_lookup_x+0x2fa (/usr/lib64/l>
perf 752598 349300.124854: 1000005 branches: 7f18676a90b6
_dl_lookup_symbol_x+0x56 (/usr/>
perf 752598 349300.124854: 1000005 branches: 7f18676a90b6
_dl_lookup_symbol_x+0x56 (/usr/>
perf 752598 349300.125914: 999998 branches: 7f18676a8556
do_lookup_x+0xf6 (/usr/lib64/ld>
perf 752598 349300.125914: 999998 branches: 7f18676a8556
do_lookup_x+0xf6 (/usr/lib64/ld>
perf 752598 349300.127401: 1000009 branches: 4c1adf
brstack_bench+0x15 (/home/kan/o>
perf 752598 349300.127401: 1000009 branches: 4c1adf
brstack_bench+0x15 (/home/kan/o>
Thanks,
Kan
> Thanks,
> Ian
>
next prev parent reply other threads:[~2024-06-28 20:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-14 21:39 [PATCH] perf topdown: Correct leader selection with sample_read enabled Dapeng Mi
2024-06-27 15:11 ` Liang, Kan
2024-06-28 6:17 ` Mi, Dapeng
2024-06-28 18:28 ` Ian Rogers
2024-06-28 20:27 ` Liang, Kan [this message]
2024-07-01 9:51 ` Mi, Dapeng
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=350e5bf7-23ee-4a7f-8b62-e3d07604cbe1@linux.intel.com \
--to=kan.liang@linux.intel.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=dapeng1.mi@intel.com \
--cc=dapeng1.mi@linux.intel.com \
--cc=irogers@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.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;
as well as URLs for NNTP newsgroup(s).