RFC: Performance Monitor Counters device

[Dave Engebretsen]

Segher Boessenkool wrote:
>
> David Engebretsen wrote:

> The 64-bit idea is very very nice :)  That'll allow a program to just set
> the counters at the start of eexecution, and only read them again when it's
> finished.  Can't get much simpler ;)

Of course this depends on what you are trying to achive.  For profiling
or when timeslicing the counters, this is not needed generally. If you
want to just collect a fixed set of values over a long run, it is
usefull.  This however is not the mode I have generally been finding
useful.

> I don't want to have the profiling buffers in kernel space, as they can very well
> be bigger than physical memory...  On the other hand, it might be needed for
> performance (or to avoid races) if doing very fine-grained profiling.  I think
> I'll just sneak out of this by not allowing so fine-grained stuff ;)

Not sure I follow here - allowing a profiling buffer which is even a
fraction of total system memory will significantly perturb the data.
What we have been planning here (but have not implemented) is a
mechanism to freeze the generation of trace events while the user space
application drains & processes the data into a more compact form, such
as a profile.

> > 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 :)
>
> On ppc32, userland can *always* read all pmc's.  You might consider that a
> security risk already (consider timing attacks on some crypto algo, for
> example).
> The worse issue imho is that it's pretty easy to lock up/severely slow down
> a machine by setting some idiotic values to the exception stuff.

Reading isn't really the problem :)  It is the interrupt rate
implications that are of concern.

> > 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.
>
> How do you use that second trace?  Just curious, I'm always happy to learn some
> new techniques ;)

As the input for a tool which generates a profile based on the trace
points.  For example, if you are collecting L2 miss addresses on a 32b
application and want a resolution of 1 word, the possible input values
would require a rather large buffer to use a simple profile scheme.  A
trace is a more compact representation of the data and allows fine grain
resolution without requiring a huge buffer.

Dave.

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