Messages in this thread | | | Date | Thu, 10 Jun 1999 17:28:30 +0200 | From | Andi Kleen <> | Subject | Re: release 0.2 of x86 performance-monitoring counters support patch |
| |
On Thu, Jun 10, 1999 at 10:00:39AM +0200, Mikael Pettersson wrote: > Andi Kleen writes: > > Only thing that I'm missing in your nice patch is a way to access the performance > > counters of remote processes (so that I could hack gdb to do non intrusive > > profiling a la itune). Extending the ioctls could work, although a ptrace > > extension would be nicer. > > I know. I'm currently working on the design of this feature. I will probably > represent the counter state objects as files in a pseudo filesystem, in order to > get sharing, lifetimes [the state must survive process death if there's another > process controlling it], and mmap() access right. SMP will be also have to be > considered, but I guess I can steal code from ptrace() or kill().
Yuck, that sounds far too complicated and slow. I would like the interface as lightweight as possible to avoid stealing too much cache from the debugee. What is wrong with a simple ptrace extension to read/write the performance registers?
The lifetime problem is already solved by ptrace (the debugee is reparented to the debugger and gets a SIGCHLD and can still access the zombie in a limited fashion)
ptrace basically does not care about SMP, because a ptraced process is stopped and fortunately cannot move CPUs while it is inspecting it. For virtual counters the SMP problems are handled for free in the normal context switch (no IPIs needed like for global ones)
-Andi
-- This is like TV. I don't like TV.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |