This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v5 3.1.0-rc4-tip 8/26] x86: analyze instruction and determine fixups.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]