LWN: Comments on "Jump label"

Jump label

SEJeff — Fri, 31 Dec 2010 17:25:51 +0000

32bit and 64bit x86 were merged together sometime ago. You must have missed the HUGE flamewar that resulted in ingo winning and the two being merged.

Jump label

i3839 — Tue, 02 Nov 2010 20:28:55 +0000

That's very smart, but a bit tricky to implement (at least on x86 and other archs with variable instruction lengths). I'd say go for it!

Jump label

ThomasBellman — Mon, 01 Nov 2010 20:58:40 +0000

Instead of inserting a NOP instruction, you could fill that slot with a useful instruction. Then, of course, that useful instruction must also be part of the tracepoint code, in order to have it performed when the tracepoint is enabled as well, when the original instruction is replaced with a jump.

Trade-off

giraffedata — Sat, 30 Oct 2010 22:05:17 +0000

Is there anyway to measure the actual overhead caused by the test in the current kernel ?
With the new approach, there is very little overhead

I believe "current kernel" refers to kernel code before the new approach.

I.e. What do we get in return for this complication?

Jump label

compudj — Sat, 30 Oct 2010 03:50:55 +0000

The overhead can be expected to be even lower than the static DTrace instrumentation, because jump labels, in combination with Tracepoints, branch over the whole stack setup and function call. DTrace only nops out the actual function call with a special linker phase, leaving in place the whole stack setup.

Jump label

daney — Fri, 29 Oct 2010 21:18:00 +0000

Indeed, although it now looks like the GCC issue has been sorted out, so those that like living on the bleeding edge can have their jump label on i386 too.

Jump label

nix — Fri, 29 Oct 2010 15:31:18 +0000

Of course jit is coming soon. We already *have* git, so this should just be a matter of a few ++s away (on a big-endian architecture).

Jump label

marcH — Fri, 29 Oct 2010 11:11:09 +0000

Coming soon: JIT

Jump label

nevets — Thu, 28 Oct 2010 21:41:11 +0000

It's looking like a bug just with i386. I think all other archs are fine (including x86_64). In fact, it is caused by the same thing that broke the function tracer a while back ago, with the craziness gcc does without the -maccumulate-outgoing-args option.

Trade-off

nix — Thu, 28 Oct 2010 14:50:56 +0000

It looks more than slightly reminiscent of the PLT's lazy binding trick to me.

Trade-off

CChittleborough — Thu, 28 Oct 2010 13:22:11 +0000

With the new approach, there is very little overhead in the instrumented code: either a NOP or an unconditional branch. The overhead has been moved to compile time (setting up the table of 'jump labels') and the time at which jumps are turned on or off (by calling enable_jump_label() or disable_jump_label(), which use the table to replace the NOP with a branch or vice versa).

Jump label

i3839 — Thu, 28 Oct 2010 13:09:32 +0000

There is no such thing as zero overhead. In the best case you still waste a little bit of memory per tracepoint, which all adds up to something significant if you have too many of them.

Jump label

ptman — Thu, 28 Oct 2010 07:54:49 +0000

Is this comparable to dtrace in Solaris? Zero overhead when probes are disabled?

Jump label

tcourbon — Thu, 28 Oct 2010 07:40:46 +0000

Is there anyway to measure the actual overhead caused by the test in the current kernel ? To my naive eyes this thing looks complicated (at least from the developer point of view).

(Furthermore does the x86 architecture include x86_64 ? If not it looks, again, over complicated for a not so impressive expected result.)

Jump label

epa — Thu, 28 Oct 2010 07:19:59 +0000

Thus we take another step closer to the self-compiling kernel.

Jump label

daney — Thu, 28 Oct 2010 05:37:26 +0000

Two points:

1) Jump label works on SPARC and MIPS too, not just x86.

2) Jump label doesn't work anywhere reliably due to bugs in current GCC releases.