From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Robert Richter <robert.richter@amd.com>
Cc: Ingo Molnar <mingo@elte.hu>, 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: Wed, 06 Jul 2011 19:12:48 +0200 [thread overview]
Message-ID: <1309972368.3282.317.camel@twins> (raw)
In-Reply-To: <20110706165357.GG4590@erda.amd.com>
On Wed, 2011-07-06 at 18:53 +0200, Robert Richter wrote:
> On 05.07.11 05:12:52, Ingo Molnar wrote:
> >
> > * 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/.
>
> I have to learn yet why /dev is bad and /sys is good...
Its not so much /dev is bad, as not quite suited for this.
> The system topology is always in /sys, also for device nodes. But we
> can't get a device file descriptor from /sys. I doubt /sys is capable
> to handle a device use count (need to be checked). We actually must
> grab the pmu while attaching events to it. And, user space
> implementation is must easier with /dev (see code in my previous
> mail).
Well you must not per-se, from a user's perspective there isn't much of
a difference between if the sys_perf_event_open() fails or if the
initial file open fails, in both cases he's not getting an event.
perf stat -e IBS:fetches will always have a fail against rmmod, rmmod
could complete before we try to open the file (assuming IBS is a
module).
>
> My patch also includes code that creates a device class. It is also
> visible in /sys/class/pmu/*.
So not only are you providing a duplicate of existing interfaces, you're
actually duplicating information inside sysfs as well.
next prev parent reply other threads:[~2011-07-06 17: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
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 [this message]
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=1309972368.3282.317.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=acme@ghostprotocols.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--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 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.