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 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.