Mathieu Desnoyers wrote:
quoted text
> 
> The point is to provide a way to dynamically enable code at runtime
> without noticeable performance impact on the system. It's principally
> useful to control the markers in the kernel, which can be placed in very
> frequently executed code paths. The original markers add a memory read,
> test and conditional branch at each marker site. By using the immediate
> values patchset, it goes down to a load immediate value, test and branch.
> 
> However, Ingo was still unhappy with the conditional branch, so I cooked
> this jump patching optimization on top of the immediate values. It
> looks for an expected pattern which limits the liveliness of the %al and
> ZF registers to the 3 instructions and, if it finds it, patches a jump
> located just before the mov instruction to skip the whole pattern and
> behave exactly like the conditional branch.
> 
> So basically we get code dynamically actvated by patching a single jump.
> 

Note that all these optimizations only make sense if the case where we 
*take* the "marker" is frequent, *and* the marker itself is not too 
expensive.

If that is not the case, just put in a noop that is dynamically patched 
to an INT3 or ICEBP instruction (one byte) or an INT instruction (two 
bytes), take the exception, look up the source address and revector to 
the marker code.

	-hpa
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/