commit 4d4838bad480 ("Use MAP_POPULATE to reduce pagefault when available")
was first introduced in tag v2.11.0 and never backported to stable
branches. Its purpose was to reduce the tracer fast-path latency caused
by handling minor page faults the first time a given application writes
to each page of the ring buffer after mapping them. The discussion
thread leading to this commit can be found here [1]. When using
LTTng-UST for diagnosing real-time applications with very strict
constraints, this added latency is unwanted.
That commit introduced the MAP_POPULATE flag when mapping the ring
buffer pages, which causes the kernel to pre-populate the page table
entries (PTE).
This has, however, unintended consequences for the following scenarios:
* Short-lived applications which write very little to the ring buffer end
up taking more time to start, because of the time it takes to
pre-populate all the ring buffer pages, even though they typically won't
be used by the application.
* Containerized workloads using cpusets will also end up having longer
application startup time than strictly required, and will populate
PTE for ring buffers of CPUs which are not present in the cpuset.
There are, therefore, two sets of irreconcilable requirements:
short-lived and containerized workloads benefit from lazily populating
the PTE, whereas real-time workloads benefit from pre-populating them.
This will therefore require a tunable environment variable that will let
the end-user choose the behavior for each application.
Solution
--------
Allow users to specify whether they want to pre-populate
shared memory pages within the application with an environment
variable.
LTTNG_UST_MAP_POPULATE_POLICY
If set, override the policy used to populate shared memory pages within the
application. The expected values are:
none
Do not pre-populate any pages, take minor faults on first access while
tracing.
cpu_possible Pre-populate pages for all possible CPUs in the system, as listed by /sys/devices/system/cpu/possible.
Default: none. If the policy is unknown, use the default.
Choice of the default
---------------------
Given that users with strict real-time constraints already have to setup
their tracing with specific options (see the "--read-timer"
lttng-enable-channel(3) option [2]), it makes sense that the default
is to lazily populate the ring buffer PTE, and require users with
real-time constraints to explicitly enable the pre-populate through an
environment variable.
Effect on default behavior
--------------------------
The default behavior for ring buffer PTE mapping will be changing across
LTTng-UST versions in the following way:
glibc 2.34 implements close_range(2), which is used by the ssh client
(amongst others). This needs to be overridden to make sure ssh does not
close lttng-ust file descriptors.
`len_type' of a sequence field must be of type unsigned integer. Some
provided examples in the man page were incorrectly using a type signed
integer, resulting in correct compilation, but error while decoding.
2dbe84f...
by
Kienan Stewart <email address hidden>
Fix: python lttngust agent fails when LTTNG_UST_APP_PATH is not set
Observed issue
==============
lttng-tools `tests/regression/ust/python-logging/test_python_logging`
had the following failures:
```
not ok 14 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events
not ok 27 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events
not ok 40 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events
not ok 53 - Found 0 / 5 events matching 'python-ev-test1' out of 0 events
not ok 66 - Found 0 / 1 events matching 'python-ev-test2' amongst 0 events
not ok 74 - Found 0 / 1 events matching 'python-ev-test2' amongst 0 events
not ok 82 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events
not ok 98 - Found 0 / 1 events matching 'python-ev-test2' amongst 0 events
not ok 109 - Found 0 / 5 events matching 'python-ev-test1' out of 0 events
not ok 115 - Found 0 events matching 'python-ev-test1'
not ok 121 - Found 0 / 1 events matching 'python-ev-test2' amongst 0 events
not ok 127 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events
not ok 134 - Found 0 / 10 events matching 'python-ev-test1' amongst 0 events
not ok 140 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events
not ok 146 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events
not ok 157 - Found 0 / 5 events matching 'python-ev-test1' amongst 0 events
```
Cause
=====
When the use of `LTTNG_UST_APP_PATH` was introduced[1], no default
value for `ust_app_port` was set. In the case where
`LTTNG_UST_APP_PATH` is not set in the environment the condition for
starting with the `ust_app_port` is still checked, causing the
following exception:
```
[2559145.907503] LTTng-UST warning: _init_threads(): cannot create client threads: cannot access local variable 'ust_app_port' where it is not associated with a value
```
47fa3e4...
by
Kienan Stewart <email address hidden>
Fix java client connection path when LTTNG_UST_APP_PATH is set
When LTTNG_UST_CTL_PATH is set for `lttng-sessiond`, the agent port is
at `$LTTNG_UST_CTL_PATH/agent.port`, not
`$LTTNG_UST_CTL_PATH/.lttng/agent.port`.
