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