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.

quoted

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.

quoted

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/