X-Git-Url: http://git.lttng.org./?a=blobdiff_plain;f=2.8%2Flttng-docs-2.8.txt;h=80cdf9a97056b32f8016385a150844133906318a;hb=ae1833e03b0dbdbfe2e9de0ac08b666ab79b9c25;hp=f69a074603b7dd6d1893068928bdbf66a186f50a;hpb=01b2f702118f65edddee788f1b407580b0074599;p=lttng-docs.git diff --git a/2.8/lttng-docs-2.8.txt b/2.8/lttng-docs-2.8.txt index f69a074..80cdf9a 100644 --- a/2.8/lttng-docs-2.8.txt +++ b/2.8/lttng-docs-2.8.txt @@ -1,12 +1,15 @@ The LTTng Documentation ======================= Philippe Proulx -v2.8, 14 March 2017 +v2.8, 24 July 2017 include::../common/copyright.txt[] +include::../common/warning-not-maintained.txt[] + + include::../common/welcome.txt[] @@ -357,6 +360,8 @@ becomes inactive or in real-time. [[installing-lttng]] == Installation +include::../common/warning-installation-outdated.txt[] + **LTTng** is a set of software <> which interact to <> the Linux kernel and user applications, and to <> (start and stop @@ -586,14 +591,14 @@ sudo depmod -a .Java and Python application instrumentation and tracing ==== If you need to instrument and trace <> on openSUSE, you need to build and install +applications>> on Fedora, you need to build and install LTTng-UST{nbsp}{revision} <> and pass the `--enable-java-agent-jul`, `--enable-java-agent-log4j`, or `--enable-java-agent-all` options to the `configure` script, depending on which Java logging framework you use. If you need to instrument and trace <> on openSUSE, you need to build and install +applications>> on Fedora, you need to build and install LTTng-UST{nbsp}{revision} from source and pass the `--enable-python-agent` option to the `configure` script. ==== @@ -658,14 +663,14 @@ If you use Hob: .Java and Python application instrumentation and tracing ==== If you need to instrument and trace <> on openSUSE, you need to build and install +applications>> on Yocto/OpenEmbedded, you need to build and install LTTng-UST{nbsp}{revision} <> and pass the `--enable-java-agent-jul`, `--enable-java-agent-log4j`, or `--enable-java-agent-all` options to the `configure` script, depending on which Java logging framework you use. If you need to instrument and trace <> on openSUSE, you need to build and install +applications>> on Yocto/OpenEmbedded, you need to build and install LTTng-UST{nbsp}{revision} from source and pass the `--enable-python-agent` option to the `configure` script. ==== @@ -1530,10 +1535,14 @@ as soon as a there's no space left for a new event record, whereas in discard mode, the tracer only discards the event record that doesn't fit. -In discard mode, LTTng increments a count of lost event records when -an event record is lost and saves this count to the trace. In -overwrite mode, LTTng keeps no information when it overwrites a -sub-buffer before consuming it. +In discard mode, LTTng increments a count of lost event records when an +event record is lost and saves this count to the trace. In overwrite +mode, since LTTng 2.8, LTTng increments a count of lost sub-buffers when +a sub-buffer is lost and saves this count to the trace. In this mode, +the exact number of lost event records in those lost sub-buffers is not +saved to the trace. Trace analyses can use the trace's saved discarded +event record and sub-buffer counts to decide whether or not to perform +the analyses even if trace data is known to be missing. There are a few ways to decrease your probability of losing event records. @@ -1558,8 +1567,8 @@ to configure the sub-buffer count and size for them: * **High event throughput**: In general, prefer bigger sub-buffers to lower the risk of losing event records. + -Having bigger sub-buffers also ensures a lower sub-buffer switching -frequency. +Having bigger sub-buffers also ensures a lower +<>. + The number of sub-buffers is only meaningful if you create the channel in overwrite mode: in this case, if a sub-buffer overwrite happens, the @@ -1713,7 +1722,7 @@ With so many similar terms, it's easy to get confused. An **event** is the consequence of the execution of an _instrumentation point_, like a tracepoint that you manually place in some source code, or a Linux kernel KProbe. An event is said to _occur_ at a specific -time. Different actions can be taken upon the occurance of an event, +time. Different actions can be taken upon the occurrence of an event, like record the event's payload to a buffer. An **event record** is the representation of an event in a sub-buffer. A @@ -5331,12 +5340,12 @@ MODULE_VERSION(__stringify(LTTNG_MODULES_MAJOR_VERSION) "." ---- -- -. Edit path:{probes/Makefile} and add your new kernel module object +. Edit path:{probes/KBuild} and add your new kernel module object next to the existing ones: + -- [source,make] -.path:{probes/Makefile} +.path:{probes/KBuild} ---- # ... @@ -7200,7 +7209,7 @@ event:: or a Linux kernel KProbe. + An event is said to _occur_ at a specific time. Different actions can -be taken upon the occurance of an event, like record the event's payload +be taken upon the occurrence of an event, like record the event's payload to a sub-buffer. <>::