[PATCH v5 3.1.0-rc4-tip 8/26] x86: analyze instruction and determine fixups.
Stefan Hajnoczi
stefanha@linux.vnet.ibm.com
Tue Sep 27 08:01:00 GMT 2011
On Mon, Sep 26, 2011 at 12:59:46PM -0700, Josh Stone wrote:
> On 09/23/2011 04:53 AM, Masami Hiramatsu wrote:
> >> Masami looked at this and found that SystemTap sdt.h currently requires
> >> an extra userspace memory store in order to activate probes. Each probe
> >> has a "semaphore" 16-bit counter which applications may test before
> >> hitting the probe itself. This is used to avoid overhead in
> >> applications that do expensive argument processing (e.g. creating
> >> strings) for probes.
> > Indeed, originally, those semaphores designed for such use cases.
> > However, some applications *always* use it (e.g. qemu-kvm).
>
> I found that qemu-kvm generates its tracepoints like this:
>
> static inline void trace_$name($args) {
> if (QEMU_${nameupper}_ENABLED()) {
> QEMU_${nameupper}($argnames);
> }
> }
>
> In that case, the $args are always computed to call the inline, so
> you'll basically just get a memory read, jump, NOP. There's no benefit
> from checking ENABLED() here, and removing it would leave only the NOP.
> Even if you invent an improved mechanism for ENABLED(), that doesn't
> change the fact that it's doing useless work here.
>
> So in this case, it may be better to patch qemu, assuming my statements
> hold for DTrace's implementation on other platforms too. The ENABLED()
> guard still does have other genuine uses though, as with the string
> preparation in Python's probes.
I will get qemu fixed.
Stefan
More information about the Systemtap
mailing list