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

[Robert Richter <robert.richter@amd.com>]

On 06.07.11 13:10:15, Ingo Molnar wrote:
> 
> * Robert Richter <robert.richter@amd.com> wrote:

> > I have to learn yet why /dev is bad and /sys is good...
> 
> Because /sys is already there and already carries rather rich 
> classification of various hardware components, devices and kernel 
> subsystems.
> 
> /dev/ is mostly a flat registry of classical, unstructured devices.

As already said, /sys provides system information. Of course it is
richer then. But I also don't want/need to specify a pmu that deep in
the system hierarchy. And /dev is flat and easy. What of the following
would you prefer?

 /sys/devices/pci0000:00/0000:00:03.0/usb2/2-2/2-2:1.1/input/input4/mouse0
 /dev/input/mouse0

Beside of this, you can't control devices with /sys.

> > 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).
> 
> I think Peter suggested it that an open() done in /sys should give us 
> a handle to a given event?

Using /dev solves the problems in a simple way, and simple things
often work very well. With open() we control the refcount and we then
get a device reference which is unique and immediately usable without
parsing strings. This makes user code small and intuitive and also
avoids complex config checks on the kernel side to catch wrongly
assigned events.

While we probably can live with such races now on static pmus,
thinking of future use cases like hotplugable graphic cards with pmus
in it, we actually want a clean design for this. I don't see how to do
this with sysfs. As there are no implementations yet for such an
interface, we now have the chance to design it properly.

> > My patch also includes code that creates a device class. It is also 
> > visible in /sys/class/pmu/*.
> 
> But PMU is a very limited term: what we want is a higher level 
> organization of 'event sources' and 'events'. Some may come from 
> PMUs, many wont.

You can see it as 'virtual' pmu, like the virtual file system.
Whatever the name for this is, 'event sources' is not very handy. But
don't want to change this.

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center