qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

instrument [Was: Re: [Qemu-devel] [PATCH 00/17] [RFC] static instrumenta


From: Lluís
Subject: instrument [Was: Re: [Qemu-devel] [PATCH 00/17] [RFC] static instrumentation]
Date: Mon, 25 Oct 2010 13:13:05 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Blue Swirl writes:

> On Fri, Oct 22, 2010 at 6:32 PM, Lluís <address@hidden> wrote:
>>  instrument: Handle config-time activation
>>  instrument: Add initial instrumentation example
>>  instrument: Dynamic per-CPU state of static instrumentation points
>>  instrument: Code-generation macros
>>  instrument: [all] Include instrumentation helper declarations
>>  instrument: Add FETCH point
>>  instrument: [i386] Call FETCH point
>>  instrument: Add VMEM point
>>  instrument: [all] Call VMEM point
>>  instrument: Add PLVL point
>>  instrument: [i386] Call PLVL point

> At least in these examples, the instrumentation code just prints out a
> few interesting fields, so they are almost identical to tracepoints.

Right, but that's because that is the simplest usage example I could
think of.


> The general approach seems to be that when an interesting event
> happens, call the instrumentation code directly.

That's the idea, so that one can go from calling tracing routines to
providing hand-crafted code generators.


> A lot of internal state needs to be made available to the
> instrumentation code, which is a problem if that is considered as an
> API. 

I don't get what you mean by that. In principle, only the macro
arguments and the cpu instrumentation state are used.

I tried using static inlined functions on a first draft, but
"instrument-host.h" is included on too many places and not every
argument type was available at the include point. Maybe I could try to
work this out again, such that routines are more self, contained, but
there's still the problem of CPUState poisoning.


> Perhaps this could be changed so that when the event happens, the only
> effect is that the VM is stopped with some kind of notification. Then
> a controlling application (external to QEMU) can inspect the state and
> enable/disable tracepoints as it wishes, but using only the tools that
> are available for tracepoints, QMP or GDB. Performance would be much
> lower, though.

Hmmm... as I see it, if tracing provided a two-level backend, I could
work this out.

I mean, for me, trace-points are just user-definable macros, I could
provide instrumentation points through that, such that trace.h can
include (if directed to do it) an extra user-provided header. Then,
trace.h could look like:

  #include "qemu-common.h"

  #include "trace-override.h" // user defines trace_whatever
   
  #ifndef trace_whatever
  // maybe provide a separate trace-events-override file and do not
  // generate this with tracetool from trace-events
  static inline void trace_whatever(args...)
  {
    call trace backend
  }
  #endif

Of course, instrumentation points found during code generation still
need a different treatment even if they are to be used as plain
trace-points, as they're not called at run-time unless you generate a
call to a helper, so maybe a new trace-point type should be handled on
'tracetool' (like trace_generate_<whatever> or something like that),
that generates a call to the tracing backend instead of simply calling
it.

This way, trace generation from these points can be neatly integrated
with all the other tracing points.

But still, the instrumentation state is a critical performance issue for
'trace_generate_' points.

What do you think?

Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth



reply via email to

[Prev in Thread] Current Thread [Next in Thread]