[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: Static tracepoint control via trace-event
From: |
Stefan Hajnoczi |
Subject: |
[Qemu-devel] Re: Static tracepoint control via trace-event |
Date: |
Tue, 19 Oct 2010 14:30:58 +0100 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
On Tue, Oct 19, 2010 at 03:08:08PM +0200, Jan Kiszka wrote:
> One quirk I stumbled over quickly was the "disable" tag in trace-events.
> It confused me first as qemu starts without any tracepoint enabled by
> default and I thought I had to hack the file. Then I read the doc and
> wondered which exiting or future backend would come without sufficiently
> fast dynamic tracepoint control. Do you have any in mind?
>
> Instead of making it a compile-time switch (except for simpletrace), I
> would vote for declaring the simpletrace usage as the only one: disable
> sets the default state of the dynamic tracepoint. That way we could use
> trace-events to define a useful set of standard, moderate-impact
> tracepoints that shall be on. Others will still be available once a
> backend is configured, but remain off until enabled during runtime.
> Anything else looks like overkill to me.
The motivation for "disable" producing a nop trace event is that it
allows QEMU builds without certain trace events. A trace event cannot
simply be removed by deleting its trace-events declaration since there
are calls to its trace_*() function in the source tree. So this
provided a way to disable trace events before simpletrace supported
enabling/disabling trace events at runtime :).
Today that's no longer an issue for simpletrace and other tracing
backends like LTTng UST and SystemTAP handle disabled trace events well.
I agree that keeping just one meaning for the "disable" keyword is
better. Perhaps we should keep a separate "nop" keyword to build out
specific trace events.
When would "nop" be handy? I think an ftrace backend is a good example.
Since an ftrace marker cannot be enabled/disabled at runtime, the only
way to silence unwanted trace events is to "nop" them at compile-time.
> There are a few more things I have in mind (ftrace backend, enhanced
> "-trace" switch, wildcards for enabling tracepoints, and more
> tracepoints). Will hopefully come up with patches to address them, but
> this may take a while.
Sounds great.
> PS: Do you maintain a tracing git tree?
No, I'm reviewing patches as they are posted for qemu-devel. If the
backlog between mailing list discussion and merge reaches the point
where your patches are suffering conflicts please let me know and I can
maintain one.
For the initial QEMU tracing effort I kept a tree but I stopped after
the patches were accepted into mainline. The patches I write go
straight to qemu-devel now.
Stefan