From: Ingo Molnar <mingo@elte.hu>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Robert Richter <robert.richter@amd.com>,
Paul Mackerras <paulus@samba.org>,
Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] [PATCH] perf: Attaching an event to a specific PMU
Date: Tue, 5 Jul 2011 11:12:52 +0200 [thread overview]
Message-ID: <20110705091252.GA5725@elte.hu> (raw)
In-Reply-To: <1309855905.3282.42.camel@twins>
* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > Overall, my approach improves the perf design. It adds a better
> > and more intuitve access to perf from user space with clear and
> > common methods and interfaces. Please let me know the concerns
> > you have.
>
> Its redundant, this interface ship has sailed, its not going to
> happen.
Even if we had the choice, i don't see how a /dev based enumeration
of PMUs is in any way better than a topologically attached set of
PMUs in /sys.
This kind of structure is nice in principle:
# ls -l /dev/pmu/
total 0
crw-rw---- 1 root root 254, 5 Jul 8 2011 breakpoint
crw-rw---- 1 root root 254, 4 Jul 8 2011 cpu
crw-rw---- 1 root root 254, 6 Jul 8 2011 proto
crw-rw---- 1 root root 254, 1 Jul 8 2011 software
crw-rw---- 1 root root 254, 2 Jul 8 2011 tracepoint
But it should be done in /sys/. That way for example the graphics
card:
00:02.0 VGA compatible controller
should have its events under:
/sys/devices/pci0000\:00/0000\:00\:02.0/events/
breakpoints could be listed in:
/sys/devices/system/cpu/cpu0/events/
core kernel software events could be listed in:
/sys/devices/system/core/events/
tracepoints could be listed in their respective subsystem directories:
/sys/devices/system/timekeeping/events/ # timer tracepoints
/sys/devices/system/machinecheck/events/ # the MCE tracepoint
/sys/kernel/slab/events/ # SLAB tracepoints
/sys/kernel/debug/tracing/events/ # the old, legacy location of
# tracepoint events
there should also be a /sys/class/events/ populated with symlinks to
all their locations.
Then we could transition all events to their respective sysfs
locations, where they would be easily discoverable and enumerable.
The events would also automatically move (and with time, be
automatically added) when a new device is added to sysfs.
Peter, there was a patch (from you?) that started doing this kind of
sysfs enumeration with a class added as well - do you still have it
or do you have a link to it?
Thanks,
Ingo
next prev parent reply other threads:[~2011-07-05 9:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-03 15:04 [RFC] [PATCH] perf: Attaching an event to a specific PMU Robert Richter
2011-07-03 18:04 ` Peter Zijlstra
2011-07-04 17:59 ` Robert Richter
2011-07-05 8:51 ` Peter Zijlstra
2011-07-05 9:12 ` Ingo Molnar [this message]
2011-07-06 16:53 ` Robert Richter
2011-07-06 17:10 ` Ingo Molnar
2011-07-06 17:14 ` Peter Zijlstra
2011-07-06 17:15 ` Ingo Molnar
2011-07-07 10:22 ` Robert Richter
2011-07-06 17:12 ` Peter Zijlstra
2011-07-07 9:21 ` Robert Richter
2011-07-07 9:39 ` Robert Richter
2011-07-07 19:38 ` Peter Zijlstra
2011-07-05 9:47 ` [PATCH] perf: Extend attr check to allow also dynamically generated Robert Richter
2011-07-05 10:51 ` Peter Zijlstra
2011-07-05 10:56 ` Robert Richter
2011-07-05 10:53 ` [PATCH] perf: Extend attr check to allow also dynamically generated types Robert Richter
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=20110705091252.GA5725@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@ghostprotocols.net \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.org \
--cc=robert.richter@amd.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