Blue Swirl writes:
> On Tue, Nov 9, 2010 at 2:08 PM, Lluís <xscr...@gmx.net> wrote:
>> Enable all trace events by default, assuming their frequency is relatively
>> low,
>> so there will be no measurable performace impact.
> Even if the impact for one tracepoint is low, if all tracepoints are
> enabled, eventually (considering that the number of tracepoints will
> increase) just the data flow to the trace file will start to slow down
> the guest.
> But I'm not completely opposed to removing 'disable' keyword, for
> example by turning all tracepoints off initially. Though then there
> would be no way to trace the initialization activities.
Well, the default trace backend is 'nop' so there's no overhead at all
on default compilations.
Even more, if you enable a backend other than 'nop', right now you still
have to manually (de)activate the trace-events you want, depending on
the backend you choose.
For example, right now backends behave:
* nop
No overhead regardless of the "disable" property/keyword
* simple
"disable" sets the initial event state, but they're always able to
trace (compiled-in).
* ust
If "disable" is present the event is not compiled-in, but by
default events are not tracing from the start.
* dtrace
Similar to "simple" (don't remember if "disable" has any effect at
all).
Then, with the patch I sent, "disable" always uses the "nop" backend
with that event, and otherwise follows through the default per-backend
state (all of which should have an inactive state by default).
So, my patch is just a matter of having all events available _only_ when
you use a backend other than "nop".
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
