From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3D85F54F.5C0D9187@vnet.ibm.com> Date: Mon, 16 Sep 2002 10:14:23 -0500 From: Dave Engebretsen MIME-Version: 1.0 To: Segher Boessenkool Cc: linuxppc-dev@lists.linuxppc.org Subject: Re: RFC: Performance Monitor Counters device References: <3D80F2F7.3FB3AE4B@koffie.nl> <3D8264FF.999DD217@vnet.ibm.com> <3D831BF6.EA2412E1@koffie.nl> Content-Type: text/plain; charset=us-ascii Sender: owner-linuxppc-dev@lists.linuxppc.org List-Id: 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/