From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Namhyung Kim <namhyung@kernel.org>, Ian Rogers <irogers@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Dapeng Mi <dapeng1.mi@linux.intel.com>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
Yongwei Ma <yongwei.ma@intel.com>,
Dapeng Mi <dapeng1.mi@intel.com>
Subject: Re: [Patch v5 0/6] Bug fixes on topdown events reordering
Date: Thu, 3 Oct 2024 19:29:06 -0400 [thread overview]
Message-ID: <8df24fe8-4d90-4105-acf0-e4f2667c42c9@linux.intel.com> (raw)
In-Reply-To: <Zv8XIZAwfoTtzOl4@google.com>
On 2024-10-03 6:13 p.m., Namhyung Kim wrote:
>> Dapeng's comment should cover replace the comment /* Followed by
>> topdown events. */ but there are other things amiss. I'm thinking of
>> something like: "slots,cycles,{instructions,topdown-be-bound}" the
>> topdown-be-bound should get sorted and grouped with slots, but cycles
>> and instructions have no reason to be reordered, so do we end up with
>> slots, instructions and topdown-be-bound being grouped with cycles
>> sitting ungrouped in the middle of the evlist? I believe there are
>> assumptions that grouped evsels are adjacent in the evlist, not least
>> in:
>> https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/parse-events.c?h=perf-tools-next#n2106
>> Does cycles instructions end up being broken out of a group in this
>> case? Which feels like the case the code was trying to avoid.
> I got this:
>
> $ sudo ./perf record -a -e "slots,cycles,{instructions,topdown-be-bound}" true
> Error:
> The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (topdown-be-bound).
> "dmesg | grep -i perf" may provide additional information.
To be honest, I think the "slots,cycles,{instructions,topdown-be-bound}"
is a meaningless case. Why a user wants to group instructions and
topdown events, but leave the slots out of the group?
There could be hundreds of different combinations caused by the perf
metrics mess. I don't think the re-ordering code should/can fix all of them.
For the case which the re-ordering cannot cover (like above), an error
out is acceptable. So the end user can update their command to a more
meaningful format, either {slots,cycles,instructions,topdown-be-bound}
or {slots,topdown-be-bound},cycles,instructions still works.
I think what the patch set really fixed is the failure of sample read
with perf metrics. Without the patch set, it never works no matter how
you change the order of the events.
A better ordering is just a nice to have feature. If perf cannot
provides a perfect re-ordering, I think an error out is also OK.
Thanks,
Kan
next prev parent reply other threads:[~2024-10-03 23:29 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-13 8:47 [Patch v5 0/6] Bug fixes on topdown events reordering Dapeng Mi
2024-09-13 8:47 ` [Patch v5 1/6] perf x86/topdown: Complete topdown slots/metrics events check Dapeng Mi
2024-10-08 5:55 ` Ian Rogers
2024-10-09 9:56 ` Mi, Dapeng
2024-09-13 8:47 ` [Patch v5 2/6] perf x86/topdown: Correct leader selection with sample_read enabled Dapeng Mi
2024-09-13 8:47 ` [Patch v5 3/6] perf x86/topdown: Don't move topdown metric events in group Dapeng Mi
2024-09-13 8:47 ` [Patch v5 4/6] perf tests: Add leader sampling test in record tests Dapeng Mi
2024-09-13 8:47 ` [Patch v5 5/6] perf tests: Add topdown events counting and sampling tests Dapeng Mi
2024-09-13 8:47 ` [Patch v5 6/6] perf tests: Add more topdown events regroup tests Dapeng Mi
2024-10-01 21:02 ` [Patch v5 0/6] Bug fixes on topdown events reordering Namhyung Kim
2024-10-01 22:32 ` Ian Rogers
2024-10-02 14:31 ` Ian Rogers
2024-10-03 0:00 ` Namhyung Kim
2024-10-03 0:57 ` Ian Rogers
2024-10-03 14:57 ` Liang, Kan
2024-10-03 15:55 ` Ian Rogers
2024-10-03 16:45 ` Namhyung Kim
2024-10-03 19:45 ` Liang, Kan
2024-10-03 21:26 ` Ian Rogers
2024-10-03 22:13 ` Namhyung Kim
2024-10-03 23:29 ` Liang, Kan [this message]
2024-10-03 23:36 ` Ian Rogers
2024-10-04 5:19 ` Namhyung Kim
2024-10-08 2:52 ` Mi, Dapeng1
2024-10-08 5:13 ` Ian Rogers
2024-10-08 2:31 ` Mi, Dapeng1
2024-10-08 2:30 ` Mi, Dapeng1
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=8df24fe8-4d90-4105-acf0-e4f2667c42c9@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 \
--cc=yongwei.ma@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 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).