Re: [RFC] [PATCH] perf: Attaching an event to a specific PMU

[Peter Zijlstra]

On Thu, 2011-07-07 at 11:21 +0200, Robert Richter wrote:
> On 06.07.11 13:12:48, Peter Zijlstra wrote:
> > On Wed, 2011-07-06 at 18:53 +0200, Robert Richter wrote:
> 
> > > 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.
> 
> It is not that I want to create event handles with open. 

Never said you wanted to do that.

> For this
> there is the syscall. I use open() to create a unique reference to a
> pmu in userspace. 

Yeah, and its pointless.

Which ever way around you turn this problem it always ends up looking
like:

  fd = open("/sys/foo");
  event = sys_perf_event_open();
  close(fd);
    /* do stuff */
  close(event);

The pmu not going away between the open() and sys_perf_event_open() is
irrelevant. What is required is the success of both calls, up until that
happens its a fail.

> > 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.
> 
> This is not duplication. /sys provides information about system
> hierarchy, /dev is for controlling devices. Thus, every device node is
> visible in /sys as it is part of the system.

It is duplication, we already have a /sys representation of every pmu,
by adding /sys/class/pmu/ you add another, that's pure duplication.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/