Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108]

Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108]

[Frank Ch. Eigler]

Hi -

On Fri, Sep 15, 2006 at 07:31:48PM +0100, Alan Cox wrote:
> Ar Gwe, 2006-09-15 am 13:08 -0400, ysgrifennodd Frank Ch. Eigler:
Yeah, or something. :-)

> > Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> > - where 1000-cycle int3-dispatching overheads too high
> 
> Why are your despatching overheads 1000 cycles ? (and if its due to int3
> why are you using int 3 8))

Smart teams from IBM and Hitachi have been hammering away at this code
for a year or two now, and yet (roughly) here we are.  There have been
experiments involving plopping branches instead of int3's at probe
locations, but this is self-modifying code involving multiple
instructions, and appears to be tricky on SMP/preempt boxes.

- FChE

Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108]

[Alan Cox]

Ar Gwe, 2006-09-15 am 14:34 -0400, ysgrifennodd Frank Ch. Eigler:
> locations, but this is self-modifying code involving multiple
> instructions, and appears to be tricky on SMP/preempt boxes.

Can you explain more about why this is the case. I would have though
that it's the same with one instruction or 100 to the non SMP case. You
may never patch an instruction while another CPU may be executing that
path and there must be a synchronizing point for each CPU before it hits
the patched instruction. See the Intel and AMD chip errata documents.

Figuring out how long to patch is a more complicated problem but there
is extant code to compute the length of an x86 instruction.


Alan