Messages in this thread | | | Date | Wed, 13 Jan 2010 18:21:20 -0800 | Subject | Re: HW breakpoints perf_events request | From | Joshua Pincus <> |
| |
Hi,
On Wed, Jan 13, 2010 at 6:15 PM, Andi Kleen <andi@firstfloor.org> wrote: > Joshua Pincus <joshua.pincus@gmail.com> writes: > >> I have a request for an additional feature to be included >> in the recent hardware breakpoints work soon to be delivered >> in kernel 2.6.33. > > Sounds to me like the existing ptrace based interface > can practically all you want > > (except that the "parent signal" would be wait and for > fork/exec you have to explicitely attach)
We would like to avoid using ptrace at all costs. It requires us to have a parent thread running which monitors all the others. It's not clear that the wait() call by the parent doesn't mask a barrage of signals from various threads and the performance penalty is huge in multi-threaded apps.
If we could get this functionality working w/o ptrace, we'd be very, very happy and grateful.
> > -Andi >
Thanks, JP -- On Wed, Jan 13, 2010 at 6:15 PM, Andi Kleen <andi@firstfloor.org> wrote: > Joshua Pincus <joshua.pincus@gmail.com> writes: > >> I have a request for an additional feature to be included >> in the recent hardware breakpoints work soon to be delivered >> in kernel 2.6.33. > > Sounds to me like the existing ptrace based interface > can practically all you want > > (except that the "parent signal" would be wait and for > fork/exec you have to explicitely attach) > > -Andi > > -- > ak@linux.intel.com -- Speaking for myself only. >
| |