RFC: Performance Monitor Counters device

[David Engebretsen]

Segher Boessenkool wrote:
>
> Hi people,
>
> I'm currently implementing a Linux driver to use the PowerPC
> performance monitor counters (PMC's).  I thought I'd ask here

> The goal of this driver is threefold:
>
> 1) provide an easy interface for programs to be able to monitor
>    themselves -> need to change your programs code, very
>    fine-grained profiling.
> 2) provide a little more capable interface to use with something
>    like gmon.
> 3) and you can do all that on the kernel, too.
>

In ppc64, we have implemented a generic interface via a syscall (which is akin
to what IA64 has done).  Though this syscall interface, a user level program can
confure the counters to collect pretty much any desired data.  The kernel puts
the data in the PMCs, collects a trace of SIAR & SDAR values, maintians a
cumulative count in 64b data structures, etc.  The traces are nice as they
include data from the entire kernel, inlcluding area where runing hard
disabled.  I think most of this is in our trees (see perfmon.[ch], although
there are some recent additions I am still cleaning up which should be ready in
a week or so.

The present code only allows the kernel to be profiled and for a mode which
collects slices of data by rotating through the counters during a run
(collecting CPI, cache miss rates, branch mispredicts, etc).  We have not yet
added any user space collection, other than a quick proof of concept hack.


> 1) What's the best interface for this kind of thing?  A char
>    device?  With ioctl()'s?  a sysctl?  something in /proc?
>    I'm not interested in ease of implementation (I'll have to
>    hack some on gprof too, for this -- so I'm not afraid of
>    the kernel ;) ), but in what's philosophically/technically/
>    procatically the best interface.

The interface question is one I have been concerned with too.  We chose a
syscall as it was quickest to implement & is efficient.  A driver with ioctls or
/proc are also good candidates for discussion.

> 4) Security: I want to generate most of the settings in userland,
>    for maximum ease of use and ease of implementation; but that
>    brings up some security issues.  Only allowing root to
>    profile code isn't ideal, either.  So:
>    a) Don't automagically load the module; if root loads it, let's
>       hope he knows what he's doing;
>    b) Have the pmc device be accessible only to a 'trusted' group;
>    c) A setuid driver program to start profiling;
>    d) Something much more clever?

What we have implemented to date does raise security issues as by exposing this
hardware to a user it will allow them to severely affect the system.  Only idea
we have had thus far is assume root knows what they are doing :)

Anton had mentioned in a followup about integration into oprofile or other
tools.  This would be nice to consider as well.  Presently the data generated by
our tools is in one of two very simple formats: one is just a kernel profile
(just like the standard kernel profiler), the other is a trace containing pairs
of SIAR and SDAR registers.

Dave.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/