This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH v5 3.1.0-rc4-tip 8/26] x86: analyze instruction and determine fixups.
- From: Stefan Hajnoczi <stefanha at linux dot vnet dot ibm dot com>
- To: Josh Stone <jistone at redhat dot com>
- Cc: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>, Christoph Hellwig <hch at infradead dot org>, Srikar Dronamraju <srikar at linux dot vnet dot ibm dot com>, Peter Zijlstra <peterz at infradead dot org>, Ingo Molnar <mingo at elte dot hu>, Steven Rostedt <rostedt at goodmis dot org>, Linux-mm <linux-mm at kvack dot org>, SystemTap <systemtap at sourceware dot org>
- Date: Tue, 27 Sep 2011 08:08:47 +0100
- Subject: Re: [PATCH v5 3.1.0-rc4-tip 8/26] x86: analyze instruction and determine fixups.
- References: <20110920115938.25326.93059.sendpatchset@srdronam.in.ibm.com> <20110920120127.25326.71509.sendpatchset@srdronam.in.ibm.com> <20110920171310.GC27959@stefanha-thinkpad.localdomain> <20110920181225.GA5149@infradead.org> <20110923165132.GA23870@stefanha-thinkpad.localdomain> <4E80D9B2.3010404@redhat.com>
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