From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
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>, Jiri Olsa <jolsa@kernel.org>,
Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>
Subject: Re: [PATCH] perf/core: move all of the pmu devices into their own location
Date: Tue, 4 Feb 2025 13:23:51 -0500 [thread overview]
Message-ID: <9656a86c-30fb-48d9-9327-920cd449e73a@linux.intel.com> (raw)
In-Reply-To: <2025020408-apron-fled-d29e@gregkh>
On 2025-02-04 11:28 a.m., Greg Kroah-Hartman wrote:
> On Tue, Feb 04, 2025 at 09:06:18AM -0500, Liang, Kan wrote:
>>
>>
>> On 2025-02-04 5:16 a.m., Greg Kroah-Hartman wrote:
>>> On Tue, Feb 04, 2025 at 09:41:03AM +0200, Alexander Shishkin wrote:
>>>> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
>>>>
>>>>> In sysfs, for some reason, all pmu devices seem to show up in the "root"
>>>>> of /sys/devices/ making for a confusing mess as these devices are not
>>>>> really at the root of the system at all.
>>>>>
>>>>> Create a fake root devices, "pmu_bus" and place them all under there if
>>>>> they do not already have a parent device set, cleaning up sysfs to look
>>>>> more sane.
>>>>
>>>> Yeah, so what happens to the userspace that uses them via /sys/devices/*
>>>> directly? Even I have scripts that do that.
>>>
>>> You should never be doing that, as you have no idea what type of devices
>>> are in that location in the tree. You should be doing what the
>>> documentation says to do, and look in /sys/bus/event_source/devices/
>>> instead. That didn't change here.
>>>
>>
>> Not just the script, the /sys/devices/ is also used in the current perf
>> tool. For example,
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/util/mem-events.c#n192
>>
>> And the comments and document in the perf tool.
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/util/pmu.c#n39
>
> Note, this file looks to work properly, it's just the comment that is
> incorrect.
>
> Any hints on what perf command or test I should run to verify I did get
> this all right?
For the perf tool, "perf test" should be run at minimum.
>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/Documentation/perf-list.txt#n191
>
> I'll fix that.
>
>> I think it should bring big impact for the end user, especially when
>> they still use an older perf tool and script.
>
> It seems that the majority of the perf code IS looking in the correct
> place, just mem-events.c seemed wrong.
>
There should be two more.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/builtin-stat.c#n100
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/arch/x86/util/iostat.c#n35
Thanks,
Kan
next prev parent reply other threads:[~2025-02-04 18:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-03 19:25 [PATCH] perf/core: move all of the pmu devices into their own location Greg Kroah-Hartman
2025-02-03 19:44 ` Ian Rogers
2025-02-04 7:05 ` Greg Kroah-Hartman
2025-02-04 18:17 ` Ian Rogers
2025-02-05 5:41 ` Greg Kroah-Hartman
2025-02-05 16:48 ` Ian Rogers
2025-02-05 18:45 ` Greg Kroah-Hartman
2025-02-04 7:41 ` Alexander Shishkin
2025-02-04 10:16 ` Greg Kroah-Hartman
2025-02-04 14:06 ` Liang, Kan
2025-02-04 15:21 ` Greg Kroah-Hartman
2025-02-04 16:28 ` Greg Kroah-Hartman
2025-02-04 16:41 ` Vince Weaver
2025-02-04 17:12 ` Greg Kroah-Hartman
2025-02-04 17:49 ` Ian Rogers
2025-02-04 18:03 ` Greg Kroah-Hartman
2025-02-05 1:21 ` Vince Weaver
2025-02-05 5:45 ` Greg Kroah-Hartman
2025-02-05 15:06 ` Vince Weaver
2025-02-05 15:36 ` Greg Kroah-Hartman
2025-02-04 18:23 ` Liang, Kan [this message]
2025-02-05 16:00 ` Greg Kroah-Hartman
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=9656a86c-30fb-48d9-9327-920cd449e73a@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=gregkh@linuxfoundation.org \
--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.