Patchwork [01/10] trace: [doc] Document event properties on a separate section

login
register
mail settings
Submitter Lluís Vilanova
Date Dec. 8, 2011, 10:48 p.m.
Message ID <20111208224807.21668.94467.stgit@ginnungagap.bsc.es>
Download mbox | patch
Permalink /patch/130251/
State New
Headers show

Comments

Lluís Vilanova - Dec. 8, 2011, 10:48 p.m.
Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
---
 docs/tracing.txt |   22 ++++++++++++++++------
 1 files changed, 16 insertions(+), 6 deletions(-)
Lluís Vilanova - Dec. 9, 2011, 8:08 p.m.
This series must be updated to apply on top of the patch recently accepted by
Stefan into the tracing tree [1].

[1] http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00763.html


Lluis

Lluís Vilanova writes:

> Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
> ---
>  docs/tracing.txt |   22 ++++++++++++++++------
>  1 files changed, 16 insertions(+), 6 deletions(-)

> diff --git a/docs/tracing.txt b/docs/tracing.txt
> index ea29f2c..853cbf8 100644
> --- a/docs/tracing.txt
> +++ b/docs/tracing.txt
> @@ -98,12 +98,6 @@ respectively.  This ensures portability between 32- and 64-bit platforms.
>  4. Name trace events after their function.  If there are multiple trace events
>     in one function, append a unique distinguisher at the end of the name.
 
> -5. If specific trace events are going to be called a huge number of times, this
> -   might have a noticeable performance impact even when the trace events are
> -   programmatically disabled. In this case you should declare the trace event
> -   with the "disable" property, which will effectively disable it at compile
> -   time (using the "nop" backend).
> -
>  == Generic interface and monitor commands ==
 
>  You can programmatically query and control the dynamic state of trace events
> @@ -234,3 +228,19 @@ probes:
>                        --target-type system \
>                        --target-arch x86_64 \
>                        <trace-events >qemu.stp
> +
> +== Trace event properties ==
> +
> +Each event in the "trace-events" file can be prefixed with a space-separated
> +list of zero or more of the following event properties.
> +
> +=== "disable" ===
> +
> +If a specific trace event is going to be invoked a huge number of times, this
> +might have a noticeable performance impact even when the event is
> +programmatically disabled.
> +
> +In this case you should declare such event with the "disable" property. This
> +will effectively disable the event at compile time (by using the "nop" backend),
> +thus having no performance impact at all on regular builds (i.e., unless you
> +edit the "trace-events" file).

Patch

diff --git a/docs/tracing.txt b/docs/tracing.txt
index ea29f2c..853cbf8 100644
--- a/docs/tracing.txt
+++ b/docs/tracing.txt
@@ -98,12 +98,6 @@  respectively.  This ensures portability between 32- and 64-bit platforms.
 4. Name trace events after their function.  If there are multiple trace events
    in one function, append a unique distinguisher at the end of the name.
 
-5. If specific trace events are going to be called a huge number of times, this
-   might have a noticeable performance impact even when the trace events are
-   programmatically disabled. In this case you should declare the trace event
-   with the "disable" property, which will effectively disable it at compile
-   time (using the "nop" backend).
-
 == Generic interface and monitor commands ==
 
 You can programmatically query and control the dynamic state of trace events
@@ -234,3 +228,19 @@  probes:
                       --target-type system \
                       --target-arch x86_64 \
                       <trace-events >qemu.stp
+
+== Trace event properties ==
+
+Each event in the "trace-events" file can be prefixed with a space-separated
+list of zero or more of the following event properties.
+
+=== "disable" ===
+
+If a specific trace event is going to be invoked a huge number of times, this
+might have a noticeable performance impact even when the event is
+programmatically disabled.
+
+In this case you should declare such event with the "disable" property. This
+will effectively disable the event at compile time (by using the "nop" backend),
+thus having no performance impact at all on regular builds (i.e., unless you
+edit the "trace-events" file).