From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Ian Rogers <irogers@google.com>
Cc: 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>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH v1] perf metrics: Remove the "No_group" metric group
Date: Thu, 4 Apr 2024 16:29:34 -0400 [thread overview]
Message-ID: <ceca5922-6b83-464f-9e64-e8999068f734@linux.intel.com> (raw)
In-Reply-To: <CAP-5=fX+YuEgD4pF-2YRcqgD2cwLw_7Z4ak+wszctvagPS+Xbw@mail.gmail.com>
On 2024-04-03 4:26 p.m., Ian Rogers wrote:
> On Wed, Apr 3, 2024 at 11:57 AM Liang, Kan <kan.liang@linux.intel.com> wrote:
>>
>>
>>
>> On 2024-04-03 2:31 p.m., Ian Rogers wrote:
>>> On Wed, Apr 3, 2024 at 10:59 AM Liang, Kan <kan.liang@linux.intel.com> wrote:
>>>>
>>>>
>>>>
>>>> On 2024-04-03 12:46 p.m., Ian Rogers wrote:
>>>>> Rather than place metrics without a metric group in "No_group" place
>>>>> them in a a metric group that is their name. Still allow such metrics
>>>>> to be selected if "No_group" is passed, this change just impacts perf
>>>>> list.
>>>>
>>>> So it looks like the "No_group" is not completely removed.
>>>> They are just not seen in the perf list, but users can still use it via
>>>> perf stat -M No_group, right?
>>>>
>>>> If so, why we want to remove it from perf list? Where can the end user
>>>> know which metrics are included in the No_group?
>>>>
>>>> If the No_group is useless, why not completely remove it?
>>>
>>> Agreed. For command line argument deprecation we usually keep the
>>> option but hide it from help with PARSE_OPT_HIDDEN, so I was trying to
>>> follow that pattern albeit that a metric group isn't a command line
>>> option it's an option to an option.
>>>
>>
>> Perf list has a deprecated option to show the deprecated events.
>> The "No_group" should be a deprecated metrics group.
>>
>> If so, to follow the same pattern, I think perf list should still
>> display the "No_group" with the --deprecated option at least.
>
> Such metrics would be shown twice, once under No_group and once under
> a metric group of their name.
You mean with the --deprecated option?
Yes, that's because the old/deprecated metrics group (No_group) is not
complete removed. So both the new name and old/deprecated name are shown
with the --deprecated option. The metrics which belong to both groups
will be shown twice.
Without the --deprecated option, only the new group and its members are
shown.
> With deprecated events this isn't the
> case, you can only see them with --deprecated. Given we can see the
> metric without the No_group grouping, what is being added by having a
> No_group grouping? It feels entirely redundant and something we don't
> need to advertise.
I just want to have a generic pattern for deprecating a metrics/metrics
group that everybody can follow.
I treat the "No_group" as a normal metrics group name. So this patch is
to introduce a new name, and hide the old name. Both new and old names
can still be used.
If it's for a deprecated event, the expectation is to only see the new
name by default, and see both new name and old name with the
--deprecated option.
Now, if it's a generic deprecated metrics group, what's the expected
behavior? I prefer to follow the same pattern as a deprecated event.
If we do so, yes, there will be some redundancy with the --deprecated
option, since some members may belong to both old and new groups.
But I don't think it's an issue. It's normal that metrics belong to
different groups.
Thanks,
Kan
next prev parent reply other threads:[~2024-04-04 20:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-03 16:46 [PATCH v1] perf metrics: Remove the "No_group" metric group Ian Rogers
2024-04-03 17:59 ` Liang, Kan
2024-04-03 18:31 ` Ian Rogers
2024-04-03 18:57 ` Liang, Kan
2024-04-03 20:26 ` Ian Rogers
2024-04-04 20:29 ` Liang, Kan [this message]
2024-04-05 1:16 ` Ian Rogers
2024-04-05 14:44 ` Liang, Kan
2024-04-03 18:44 ` Andi Kleen
2024-04-03 20:23 ` Ian Rogers
2024-04-05 14:45 ` Liang, Kan
2024-04-08 14:51 ` Arnaldo Carvalho de Melo
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=ceca5922-6b83-464f-9e64-e8999068f734@linux.intel.com \
--to=kan.liang@linux.intel.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@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=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).