Re: [lttng-dev] [PATCH v2] Improve tracef/tracelog to use the stack for small strings
Am Mo., 1. Aug. 2022 um 16:35 Uhr schrieb Norbert Lange :
>
> From: Norbert Lange
>
> Support two common cases, one being that the resulting message is
> small enough to fit into a on-stack buffer.
> The seconds being the common 'printf("%s", "Message")' scheme.
>
> Unfortunately, iterating a va_list is destructive,
> so it has to be copied before calling vprintf.
>
> The implementation was moved to a separate file,
> used by both tracef.c and tracelog.c.
>
> Signed-off-by: Norbert Lange
> ---
> v2 -> v3:
>
> * Wrap macro in do/while
> * drop loop
> * other changes in response to feedback
>
> v2:
> - move define into src/common/tracer.h
> see https://lists.lttng.org/pipermail/lttng-dev/2021-May/029977.html
> - moved macro magic into common tracelog-internal.h header
> - rebased onto master
> ---
> src/common/tracer.h | 2 +
> src/lib/lttng-ust/tracef.c| 32 +++--
> src/lib/lttng-ust/tracelog-internal.h | 95 +++
> src/lib/lttng-ust/tracelog.c | 40 +++
> 4 files changed, 114 insertions(+), 55 deletions(-)
> create mode 100644 src/lib/lttng-ust/tracelog-internal.h
>
> diff --git a/src/common/tracer.h b/src/common/tracer.h
> index 2affd6ab..8e18c9b5 100644
> --- a/src/common/tracer.h
> +++ b/src/common/tracer.h
> @@ -26,6 +26,8 @@
> #define LTTNG_RFLAG_EXTENDED RING_BUFFER_RFLAG_END
> #define LTTNG_RFLAG_END(LTTNG_RFLAG_EXTENDED << 1)
>
> +#define LTTNG_TRACE_PRINTF_BUFSIZE 512
> +
> /*
> * LTTng client type enumeration. Used by the consumer to map the
> * callbacks from its own address space.
> diff --git a/src/lib/lttng-ust/tracef.c b/src/lib/lttng-ust/tracef.c
> index c05c7811..92911e1d 100644
> --- a/src/lib/lttng-ust/tracef.c
> +++ b/src/lib/lttng-ust/tracef.c
> @@ -7,6 +7,7 @@
> #define _LGPL_SOURCE
> #include
> #include "common/macros.h"
> +#include "common/tracer.h"
>
> /* The tracepoint definition is public, but the provider definition is
> hidden. */
> #define LTTNG_UST_TRACEPOINT_PROVIDER_HIDDEN_DEFINITION
> @@ -15,39 +16,22 @@
> #define LTTNG_UST_TRACEPOINT_DEFINE
> #include "lttng-ust-tracef-provider.h"
>
> -static inline
> -void lttng_ust___vtracef(const char *fmt, va_list ap)
> - __attribute__((always_inline, format(printf, 1, 0)));
> -static inline
> -void lttng_ust___vtracef(const char *fmt, va_list ap)
> -{
> - char *msg;
> - const int len = vasprintf(, fmt, ap);
> -
> - /* len does not include the final \0 */
> - if (len < 0)
> - goto end;
> - lttng_ust_tracepoint_cb_lttng_ust_tracef___event(msg, len,
> - LTTNG_UST_CALLER_IP());
> - free(msg);
> -end:
> - return;
> -}
> +#include "tracelog-internal.h"
>
> void lttng_ust__vtracef(const char *fmt, va_list ap)
> __attribute__((format(printf, 1, 0)));
> void lttng_ust__vtracef(const char *fmt, va_list ap)
> {
> - lttng_ust___vtracef(fmt, ap);
> + LTTNG_UST_TRACELOG_VALIST(fmt, ap,
> + lttng_ust_tracepoint_cb_lttng_ust_tracef___event,
> + msg, len, LTTNG_UST_CALLER_IP());
> }
>
> void lttng_ust__tracef(const char *fmt, ...)
> __attribute__((format(printf, 1, 2)));
> void lttng_ust__tracef(const char *fmt, ...)
> {
> - va_list ap;
> -
> - va_start(ap, fmt);
> - lttng_ust___vtracef(fmt, ap);
> - va_end(ap);
> + LTTNG_UST_TRACELOG_VARARG(fmt,
> + lttng_ust_tracepoint_cb_lttng_ust_tracef___event,
> + msg, len, LTTNG_UST_CALLER_IP());
> }
> diff --git a/src/lib/lttng-ust/tracelog-internal.h
> b/src/lib/lttng-ust/tracelog-internal.h
> new file mode 100644
> index ..34537023
> --- /dev/null
> +++ b/src/lib/lttng-ust/tracelog-internal.h
> @@ -0,0 +1,95 @@
> +/*
> + * SPDX-License-Identifier: MIT
> + *
> + * Copyright (C) 2013-2014 Mathieu Desnoyers
> + * Copyright (C) 2021 Norbert Lange
> + *
> + * Shared helper macro for tracelog and tracef.
> + */
> +
> +#define LTTNG_UST_TRACELOG_VARARG(fmt, callback, ...) \
> + do { \
> + va_list ap; \
> + char local_buf[LTTNG_TRACE_PRINTF_BUFSIZE]; \
> + size_t len = 0; \
> + char *msg = local_buf; \
> + char *alloc_buff = NULL; \
> +\
> + if (caa_unlikely(fmt[0] == '%' && fmt[1] == 's' && fmt[2] ==
> '\0')) { \
> + va_start(ap, fmt); \
> + msg = va_arg(ap, char *); \
> + va_end(ap); \
> + len = strlen(msg); \
> + } else { \
> + int ret; \
> + size_t buflen = sizeof(local_buf); \
> +\
> + /* On-stack buffer attempt */ \
> + va_start(ap, fmt); \
> + ret = vsnprintf(msg, buflen, fmt, ap); \
> + va_end(ap); \
> + if
[lttng-dev] [PATCH v2 1/2] lttng_ust_init_thread: initialise cached context values
From: Norbert Lange
Modify all relevant *_alloc_tls functions so that they take
flags for 'init'. Rename them to init_thread for consistency.
So far define one flag LTTNG_UST_INIT_THREAD_CONTEXT_CACHE,
this will warm up cached values so less is done during
the first tracepoint.
The function 'lttng_ust_init_thread' will use all available
flags, software can opt-in to do work early instead
of lazily during tracepoints.
Signed-off-by: Norbert Lange
---
v1 -> v2:
* instead of a bool, use a flag variable
* try to improve consistency for some funciton names
v1:
* see
https://lore.kernel.org/all/CADYdroN3=pae66crtsvt9ahe4t+bt61-tvhfkcuwzykhhuy...@mail.gmail.com/
* Will update docs after review, and do some more tests
during the week
---
src/lib/lttng-ust/lttng-context-cgroup-ns.c | 4 ++-
src/lib/lttng-ust/lttng-context-ipc-ns.c | 4 ++-
src/lib/lttng-ust/lttng-context-net-ns.c | 4 ++-
.../lttng-ust/lttng-context-perf-counters.c | 3 +-
src/lib/lttng-ust/lttng-context-procname.c| 4 ++-
src/lib/lttng-ust/lttng-context-provider.c| 4 +--
src/lib/lttng-ust/lttng-context-time-ns.c | 4 ++-
src/lib/lttng-ust/lttng-context-uts-ns.c | 4 ++-
src/lib/lttng-ust/lttng-context-vtid.c| 4 ++-
src/lib/lttng-ust/lttng-probes.c | 4 +--
src/lib/lttng-ust/lttng-tracer-core.h | 26 --
src/lib/lttng-ust/lttng-ust-comm.c| 34 +--
src/lib/lttng-ust/lttng-ust-statedump.c | 2 +-
13 files changed, 61 insertions(+), 40 deletions(-)
diff --git a/src/lib/lttng-ust/lttng-context-cgroup-ns.c
b/src/lib/lttng-ust/lttng-context-cgroup-ns.c
index 34523ea1..5accd2df 100644
--- a/src/lib/lttng-ust/lttng-context-cgroup-ns.c
+++ b/src/lib/lttng-ust/lttng-context-cgroup-ns.c
@@ -155,7 +155,9 @@ error_find_context:
/*
* Force a read (imply TLS allocation for dlopen) of TLS variables.
*/
-void lttng_cgroup_ns_alloc_tls(void)
+void lttng_ust_cgroup_ns_init_thread(int flags)
{
asm volatile ("" : : "m" (URCU_TLS(cached_cgroup_ns)));
+ if (flags & LTTNG_UST_INIT_THREAD_CONTEXT_CACHE)
+ (void)get_cgroup_ns();
}
diff --git a/src/lib/lttng-ust/lttng-context-ipc-ns.c
b/src/lib/lttng-ust/lttng-context-ipc-ns.c
index 63401e8d..078e6461 100644
--- a/src/lib/lttng-ust/lttng-context-ipc-ns.c
+++ b/src/lib/lttng-ust/lttng-context-ipc-ns.c
@@ -153,7 +153,9 @@ error_find_context:
/*
* Force a read (imply TLS allocation for dlopen) of TLS variables.
*/
-void lttng_ipc_ns_alloc_tls(void)
+void lttng_ust_ipc_ns_init_thread(int flags)
{
asm volatile ("" : : "m" (URCU_TLS(cached_ipc_ns)));
+ if (flags & LTTNG_UST_INIT_THREAD_CONTEXT_CACHE)
+ (void)get_ipc_ns();
}
diff --git a/src/lib/lttng-ust/lttng-context-net-ns.c
b/src/lib/lttng-ust/lttng-context-net-ns.c
index 960591c2..66fcb045 100644
--- a/src/lib/lttng-ust/lttng-context-net-ns.c
+++ b/src/lib/lttng-ust/lttng-context-net-ns.c
@@ -153,7 +153,9 @@ error_find_context:
/*
* Force a read (imply TLS allocation for dlopen) of TLS variables.
*/
-void lttng_net_ns_alloc_tls(void)
+void lttng_ust_net_ns_init_thread(int flags)
{
asm volatile ("" : : "m" (URCU_TLS(cached_net_ns)));
+ if (flags & LTTNG_UST_INIT_THREAD_CONTEXT_CACHE)
+ (void)get_net_ns();
}
diff --git a/src/lib/lttng-ust/lttng-context-perf-counters.c
b/src/lib/lttng-ust/lttng-context-perf-counters.c
index 2db11436..52371a0d 100644
--- a/src/lib/lttng-ust/lttng-context-perf-counters.c
+++ b/src/lib/lttng-ust/lttng-context-perf-counters.c
@@ -87,9 +87,10 @@ static DEFINE_URCU_TLS(int, ust_perf_mutex_nest);
/*
* Force a read (imply TLS allocation for dlopen) of TLS variables.
*/
-void lttng_ust_perf_counter_alloc_tls(void)
+void lttng_ust_perf_counter_init_thread(int flags)
{
asm volatile ("" : : "m" (URCU_TLS(ust_perf_mutex_nest)));
+ (void)flags;
}
void lttng_perf_lock(void)
diff --git a/src/lib/lttng-ust/lttng-context-procname.c
b/src/lib/lttng-ust/lttng-context-procname.c
index b5bf77be..16f34c46 100644
--- a/src/lib/lttng-ust/lttng-context-procname.c
+++ b/src/lib/lttng-ust/lttng-context-procname.c
@@ -122,7 +122,9 @@ error_find_context:
/*
* Force a read (imply TLS allocation for dlopen) of TLS variables.
*/
-void lttng_procname_alloc_tls(void)
+void lttng_ust_procname_init_thread(int flags)
{
asm volatile ("" : : "m" (URCU_TLS(cached_procname)[0]));
+ if (flags & LTTNG_UST_INIT_THREAD_CONTEXT_CACHE)
+ (void)wrapper_getprocname();
}
diff --git a/src/lib/lttng-ust/lttng-context-provider.c
b/src/lib/lttng-ust/lttng-context-provider.c
index 4e7e429f..5000657d 100644
--- a/src/lib/lttng-ust/lttng-context-provider.c
+++ b/src/lib/lttng-ust/lttng-context-provider.c
@@ -67,7 +67,7 @@ struct lttng_ust_registered_context_provider
*lttng_ust_context_provider_registe
size_t name_len = strlen(provider->name);
uint32_t hash;
-
[lttng-dev] [PATCH v2 2/2] lttng_ust_init_thread: call urcu_register_thread
From: Norbert Lange Eagerly register the thread, and avoid taking mutex during the first tracepoint. Signed-off-by: Norbert Lange Acked-by: Mathieu Desnoyers --- src/lib/lttng-ust/lttng-ust-comm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/lib/lttng-ust/lttng-ust-comm.c b/src/lib/lttng-ust/lttng-ust-comm.c index 0a039fef..0fe2da46 100644 --- a/src/lib/lttng-ust/lttng-ust-comm.c +++ b/src/lib/lttng-ust/lttng-ust-comm.c @@ -447,6 +447,8 @@ void lttng_ust_init_thread(void) * this thread attempts to use them. */ lttng_ust_common_init_thread(LTTNG_UST_INIT_THREAD_MASK); + + lttng_ust_urcu_register_thread(); } int lttng_get_notify_socket(void *owner) -- 2.35.1 ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] [PATCH v2] Improve tracef/tracelog to use the stack for small strings
From: Norbert Lange
Support two common cases, one being that the resulting message is
small enough to fit into a on-stack buffer.
The seconds being the common 'printf("%s", "Message")' scheme.
Unfortunately, iterating a va_list is destructive,
so it has to be copied before calling vprintf.
The implementation was moved to a separate file,
used by both tracef.c and tracelog.c.
Signed-off-by: Norbert Lange
---
v2 -> v3:
* Wrap macro in do/while
* drop loop
* other changes in response to feedback
v2:
- move define into src/common/tracer.h
see https://lists.lttng.org/pipermail/lttng-dev/2021-May/029977.html
- moved macro magic into common tracelog-internal.h header
- rebased onto master
---
src/common/tracer.h | 2 +
src/lib/lttng-ust/tracef.c| 32 +++--
src/lib/lttng-ust/tracelog-internal.h | 95 +++
src/lib/lttng-ust/tracelog.c | 40 +++
4 files changed, 114 insertions(+), 55 deletions(-)
create mode 100644 src/lib/lttng-ust/tracelog-internal.h
diff --git a/src/common/tracer.h b/src/common/tracer.h
index 2affd6ab..8e18c9b5 100644
--- a/src/common/tracer.h
+++ b/src/common/tracer.h
@@ -26,6 +26,8 @@
#define LTTNG_RFLAG_EXTENDED RING_BUFFER_RFLAG_END
#define LTTNG_RFLAG_END(LTTNG_RFLAG_EXTENDED << 1)
+#define LTTNG_TRACE_PRINTF_BUFSIZE 512
+
/*
* LTTng client type enumeration. Used by the consumer to map the
* callbacks from its own address space.
diff --git a/src/lib/lttng-ust/tracef.c b/src/lib/lttng-ust/tracef.c
index c05c7811..92911e1d 100644
--- a/src/lib/lttng-ust/tracef.c
+++ b/src/lib/lttng-ust/tracef.c
@@ -7,6 +7,7 @@
#define _LGPL_SOURCE
#include
#include "common/macros.h"
+#include "common/tracer.h"
/* The tracepoint definition is public, but the provider definition is hidden.
*/
#define LTTNG_UST_TRACEPOINT_PROVIDER_HIDDEN_DEFINITION
@@ -15,39 +16,22 @@
#define LTTNG_UST_TRACEPOINT_DEFINE
#include "lttng-ust-tracef-provider.h"
-static inline
-void lttng_ust___vtracef(const char *fmt, va_list ap)
- __attribute__((always_inline, format(printf, 1, 0)));
-static inline
-void lttng_ust___vtracef(const char *fmt, va_list ap)
-{
- char *msg;
- const int len = vasprintf(, fmt, ap);
-
- /* len does not include the final \0 */
- if (len < 0)
- goto end;
- lttng_ust_tracepoint_cb_lttng_ust_tracef___event(msg, len,
- LTTNG_UST_CALLER_IP());
- free(msg);
-end:
- return;
-}
+#include "tracelog-internal.h"
void lttng_ust__vtracef(const char *fmt, va_list ap)
__attribute__((format(printf, 1, 0)));
void lttng_ust__vtracef(const char *fmt, va_list ap)
{
- lttng_ust___vtracef(fmt, ap);
+ LTTNG_UST_TRACELOG_VALIST(fmt, ap,
+ lttng_ust_tracepoint_cb_lttng_ust_tracef___event,
+ msg, len, LTTNG_UST_CALLER_IP());
}
void lttng_ust__tracef(const char *fmt, ...)
__attribute__((format(printf, 1, 2)));
void lttng_ust__tracef(const char *fmt, ...)
{
- va_list ap;
-
- va_start(ap, fmt);
- lttng_ust___vtracef(fmt, ap);
- va_end(ap);
+ LTTNG_UST_TRACELOG_VARARG(fmt,
+ lttng_ust_tracepoint_cb_lttng_ust_tracef___event,
+ msg, len, LTTNG_UST_CALLER_IP());
}
diff --git a/src/lib/lttng-ust/tracelog-internal.h
b/src/lib/lttng-ust/tracelog-internal.h
new file mode 100644
index ..34537023
--- /dev/null
+++ b/src/lib/lttng-ust/tracelog-internal.h
@@ -0,0 +1,95 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright (C) 2013-2014 Mathieu Desnoyers
+ * Copyright (C) 2021 Norbert Lange
+ *
+ * Shared helper macro for tracelog and tracef.
+ */
+
+#define LTTNG_UST_TRACELOG_VARARG(fmt, callback, ...) \
+ do { \
+ va_list ap; \
+ char local_buf[LTTNG_TRACE_PRINTF_BUFSIZE]; \
+ size_t len = 0; \
+ char *msg = local_buf; \
+ char *alloc_buff = NULL; \
+\
+ if (caa_unlikely(fmt[0] == '%' && fmt[1] == 's' && fmt[2] ==
'\0')) { \
+ va_start(ap, fmt); \
+ msg = va_arg(ap, char *); \
+ va_end(ap); \
+ len = strlen(msg); \
+ } else { \
+ int ret; \
+ size_t buflen = sizeof(local_buf); \
+\
+ /* On-stack buffer attempt */ \
+ va_start(ap, fmt); \
+ ret = vsnprintf(msg, buflen, fmt, ap); \
+ va_end(ap); \
+ if (caa_unlikely(ret < 0)) \
+ break; \
+ len = (size_t)ret; \
+\
+ if (caa_unlikely(len >= sizeof(local_buf))) { \
+ buflen = len + 1; \
+ alloc_buff = (char *)malloc(buflen); \
+
Re: [lttng-dev] [PATCH 1/2] lttng_ust_init_thread: initialise cached context values
Am Di., 19. Juli 2022 um 21:39 Uhr schrieb Mathieu Desnoyers : > > - On Jul 18, 2022, at 5:59 PM, Norbert Lange via lttng-dev > lttng-dev@lists.lttng.org wrote: > > > Modify all relevant *_alloc_tls functions so that they take an > > argument for 'init'. Setting this to 'true' will read > > the actual context value and store it into a thread local > > cache. > > > > The function 'lttng_ust_init_thread' will use this to > > precalculate context values. Tracepoints can then avoid > > systemcalls. > > Rather than integrating two unrelated things within "alloc_tls" > functions, I would prefer that we split things like this, e.g.: > > keep lttng_cgroup_ns_alloc_tls() as is. > > Introduce lttng_ust_cgroup_init_thread() which would > call (void)get_cgroup_ns(). > > Likewise for all other contexts. > > Thoughts ? is this just a matter of the function name? The "things" are related as they both prepare the same thread local cache. ie. rename lttng_cgroup_ns_alloc_tls(bool init) to lttng_ust_cgroup_init_thread(bool initcache)? Don't care much either way,I just usually try to limit symbols. Regards, Norbert ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] [PATCH 1/2] lttng_ust_init_thread: initialise cached context values
Modify all relevant *_alloc_tls functions so that they take an
argument for 'init'. Setting this to 'true' will read
the actual context value and store it into a thread local
cache.
The function 'lttng_ust_init_thread' will use this to
precalculate context values. Tracepoints can then avoid
systemcalls.
Signed-off-by: Norbert Lange
---
* see
https://lore.kernel.org/all/CADYdroN3=pae66crtsvt9ahe4t+bt61-tvhfkcuwzykhhuy...@mail.gmail.com/
* Will update docs after review, and do some more tests
during the week
---
src/lib/lttng-ust/lttng-context-cgroup-ns.c | 4 +++-
src/lib/lttng-ust/lttng-context-ipc-ns.c| 4 +++-
src/lib/lttng-ust/lttng-context-net-ns.c| 4 +++-
src/lib/lttng-ust/lttng-context-procname.c | 4 +++-
src/lib/lttng-ust/lttng-context-provider.c | 4 ++--
src/lib/lttng-ust/lttng-context-time-ns.c | 4 +++-
src/lib/lttng-ust/lttng-context-uts-ns.c| 4 +++-
src/lib/lttng-ust/lttng-context-vtid.c | 4 +++-
src/lib/lttng-ust/lttng-probes.c| 4 ++--
src/lib/lttng-ust/lttng-tracer-core.h | 16 +++---
src/lib/lttng-ust/lttng-ust-comm.c | 24 ++---
src/lib/lttng-ust/lttng-ust-statedump.c | 2 +-
12 files changed, 46 insertions(+), 32 deletions(-)
diff --git a/src/lib/lttng-ust/lttng-context-cgroup-ns.c
b/src/lib/lttng-ust/lttng-context-cgroup-ns.c
index 34523ea1..3eb5ab5b 100644
--- a/src/lib/lttng-ust/lttng-context-cgroup-ns.c
+++ b/src/lib/lttng-ust/lttng-context-cgroup-ns.c
@@ -155,7 +155,9 @@ error_find_context:
/*
* Force a read (imply TLS allocation for dlopen) of TLS variables.
*/
-void lttng_cgroup_ns_alloc_tls(void)
+void lttng_cgroup_ns_alloc_tls(bool init)
{
asm volatile ("" : : "m" (URCU_TLS(cached_cgroup_ns)));
+ if (init)
+ (void)get_cgroup_ns();
}
diff --git a/src/lib/lttng-ust/lttng-context-ipc-ns.c
b/src/lib/lttng-ust/lttng-context-ipc-ns.c
index 63401e8d..b68b939f 100644
--- a/src/lib/lttng-ust/lttng-context-ipc-ns.c
+++ b/src/lib/lttng-ust/lttng-context-ipc-ns.c
@@ -153,7 +153,9 @@ error_find_context:
/*
* Force a read (imply TLS allocation for dlopen) of TLS variables.
*/
-void lttng_ipc_ns_alloc_tls(void)
+void lttng_ipc_ns_alloc_tls(bool init)
{
asm volatile ("" : : "m" (URCU_TLS(cached_ipc_ns)));
+ if (init)
+ (void)get_ipc_ns();
}
diff --git a/src/lib/lttng-ust/lttng-context-net-ns.c
b/src/lib/lttng-ust/lttng-context-net-ns.c
index 960591c2..93e574ad 100644
--- a/src/lib/lttng-ust/lttng-context-net-ns.c
+++ b/src/lib/lttng-ust/lttng-context-net-ns.c
@@ -153,7 +153,9 @@ error_find_context:
/*
* Force a read (imply TLS allocation for dlopen) of TLS variables.
*/
-void lttng_net_ns_alloc_tls(void)
+void lttng_net_ns_alloc_tls(bool init)
{
asm volatile ("" : : "m" (URCU_TLS(cached_net_ns)));
+ if (init)
+ (void)get_net_ns();
}
diff --git a/src/lib/lttng-ust/lttng-context-procname.c
b/src/lib/lttng-ust/lttng-context-procname.c
index b5bf77be..95f6fe42 100644
--- a/src/lib/lttng-ust/lttng-context-procname.c
+++ b/src/lib/lttng-ust/lttng-context-procname.c
@@ -122,7 +122,9 @@ error_find_context:
/*
* Force a read (imply TLS allocation for dlopen) of TLS variables.
*/
-void lttng_procname_alloc_tls(void)
+void lttng_procname_alloc_tls(bool init)
{
asm volatile ("" : : "m" (URCU_TLS(cached_procname)[0]));
+ if (init)
+ (void)wrapper_getprocname();
}
diff --git a/src/lib/lttng-ust/lttng-context-provider.c
b/src/lib/lttng-ust/lttng-context-provider.c
index 4e7e429f..ba24aad7 100644
--- a/src/lib/lttng-ust/lttng-context-provider.c
+++ b/src/lib/lttng-ust/lttng-context-provider.c
@@ -67,7 +67,7 @@ struct lttng_ust_registered_context_provider
*lttng_ust_context_provider_registe
size_t name_len = strlen(provider->name);
uint32_t hash;
- lttng_ust_alloc_tls();
+ lttng_ust_alloc_tls(false);
/* Provider name starts with "$app.". */
if (strncmp("$app.", provider->name, strlen("$app.")) != 0)
@@ -101,7 +101,7 @@ end:
void lttng_ust_context_provider_unregister(struct
lttng_ust_registered_context_provider *reg_provider)
{
- lttng_ust_alloc_tls();
+ lttng_ust_alloc_tls(false);
if (ust_lock())
goto end;
diff --git a/src/lib/lttng-ust/lttng-context-time-ns.c
b/src/lib/lttng-ust/lttng-context-time-ns.c
index ec32a1de..a957409b 100644
--- a/src/lib/lttng-ust/lttng-context-time-ns.c
+++ b/src/lib/lttng-ust/lttng-context-time-ns.c
@@ -152,7 +152,9 @@ error_find_context:
/*
* Force a read (imply TLS allocation for dlopen) of TLS variables.
*/
-void lttng_time_ns_alloc_tls(void)
+void lttng_time_ns_alloc_tls(bool init)
{
asm volatile ("" : : "m" (URCU_TLS(cached_time_ns)));
+ if (init)
+ (void)get_time_ns();
}
diff --git a/src/lib/lttng-ust/lttng-context-uts-ns.c
b/src/lib/lttng-ust/lttng-context-uts-ns.c
index 06a978fd..0c802188 100644
---
[lttng-dev] [PATCH 2/2] lttng_ust_init_thread: call urcu_register_thread
Eagerly register the thread, and avoid taking mutex during the first tracepoint. Signed-off-by: Norbert Lange --- src/lib/lttng-ust/lttng-ust-comm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/lib/lttng-ust/lttng-ust-comm.c b/src/lib/lttng-ust/lttng-ust-comm.c index ba0bd985..3ff6b086 100644 --- a/src/lib/lttng-ust/lttng-ust-comm.c +++ b/src/lib/lttng-ust/lttng-ust-comm.c @@ -447,6 +447,8 @@ void lttng_ust_init_thread(void) * this thread attempts to use them. */ lttng_ust_alloc_tls(true); + + lttng_ust_urcu_register_thread(); } int lttng_get_notify_socket(void *owner) -- 2.35.1 ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] [PATCH] Improve tracef/tracelog to use the stack for small strings
Support two common cases, one being that the resulting message is
small enough to fit into a on-stack buffer.
The seconds being the common 'printf("%s", "Message")' scheme.
Unfortunately, iterating a va_list is destructive,
so it has to be copied before calling vprintf.
The implementation was moved to a separate file,
used by both tracef.c and tracelog.c.
Signed-off-by: Norbert Lange
---
v2:
- move define into src/common/tracer.h
see https://lists.lttng.org/pipermail/lttng-dev/2021-May/029977.html
- moved macro magic into common tracelog-internal.h header
- rebased onto master
---
src/common/tracer.h | 2 +
src/lib/lttng-ust/tracef.c| 32 +++
src/lib/lttng-ust/tracelog-internal.h | 83 +++
src/lib/lttng-ust/tracelog.c | 40 +++--
4 files changed, 102 insertions(+), 55 deletions(-)
create mode 100644 src/lib/lttng-ust/tracelog-internal.h
diff --git a/src/common/tracer.h b/src/common/tracer.h
index 2affd6ab..8e18c9b5 100644
--- a/src/common/tracer.h
+++ b/src/common/tracer.h
@@ -26,6 +26,8 @@
#define LTTNG_RFLAG_EXTENDED RING_BUFFER_RFLAG_END
#define LTTNG_RFLAG_END(LTTNG_RFLAG_EXTENDED << 1)
+#define LTTNG_TRACE_PRINTF_BUFSIZE 512
+
/*
* LTTng client type enumeration. Used by the consumer to map the
* callbacks from its own address space.
diff --git a/src/lib/lttng-ust/tracef.c b/src/lib/lttng-ust/tracef.c
index c05c7811..92911e1d 100644
--- a/src/lib/lttng-ust/tracef.c
+++ b/src/lib/lttng-ust/tracef.c
@@ -7,6 +7,7 @@
#define _LGPL_SOURCE
#include
#include "common/macros.h"
+#include "common/tracer.h"
/* The tracepoint definition is public, but the provider definition is hidden.
*/
#define LTTNG_UST_TRACEPOINT_PROVIDER_HIDDEN_DEFINITION
@@ -15,39 +16,22 @@
#define LTTNG_UST_TRACEPOINT_DEFINE
#include "lttng-ust-tracef-provider.h"
-static inline
-void lttng_ust___vtracef(const char *fmt, va_list ap)
- __attribute__((always_inline, format(printf, 1, 0)));
-static inline
-void lttng_ust___vtracef(const char *fmt, va_list ap)
-{
- char *msg;
- const int len = vasprintf(, fmt, ap);
-
- /* len does not include the final \0 */
- if (len < 0)
- goto end;
- lttng_ust_tracepoint_cb_lttng_ust_tracef___event(msg, len,
- LTTNG_UST_CALLER_IP());
- free(msg);
-end:
- return;
-}
+#include "tracelog-internal.h"
void lttng_ust__vtracef(const char *fmt, va_list ap)
__attribute__((format(printf, 1, 0)));
void lttng_ust__vtracef(const char *fmt, va_list ap)
{
- lttng_ust___vtracef(fmt, ap);
+ LTTNG_UST_TRACELOG_VALIST(fmt, ap,
+ lttng_ust_tracepoint_cb_lttng_ust_tracef___event,
+ msg, len, LTTNG_UST_CALLER_IP());
}
void lttng_ust__tracef(const char *fmt, ...)
__attribute__((format(printf, 1, 2)));
void lttng_ust__tracef(const char *fmt, ...)
{
- va_list ap;
-
- va_start(ap, fmt);
- lttng_ust___vtracef(fmt, ap);
- va_end(ap);
+ LTTNG_UST_TRACELOG_VARARG(fmt,
+ lttng_ust_tracepoint_cb_lttng_ust_tracef___event,
+ msg, len, LTTNG_UST_CALLER_IP());
}
diff --git a/src/lib/lttng-ust/tracelog-internal.h
b/src/lib/lttng-ust/tracelog-internal.h
new file mode 100644
index ..291ff27c
--- /dev/null
+++ b/src/lib/lttng-ust/tracelog-internal.h
@@ -0,0 +1,83 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright (C) 2013-2014 Mathieu Desnoyers
+ * Copyright (C) 2021 Norbert Lange
+ *
+ * Shared helper macro for tracelog and tracef
+ */
+
+#define LTTNG_UST_TRACELOG_VARARG(fmt, callback, ...) \
+ va_list ap; \
+ char local_buf[LTTNG_TRACE_PRINTF_BUFSIZE]; \
+ int len; \
+ char *msg = local_buf; \
+ size_t buflen = sizeof(local_buf); \
+ char *alloc_buff = NULL; \
+\
+ if (caa_unlikely(fmt[0] == '%' && fmt[1] == 's' && fmt[2] == '\0')) { \
+ va_start(ap, fmt); \
+ msg = va_arg(ap, char *); \
+ va_end(ap); \
+ len = strlen(msg); \
+ } else \
+ for(;;) { \
+ va_start(ap, fmt); \
+ len = vsnprintf(msg, buflen, fmt, ap); \
+ va_end(ap); \
+\
+ if (caa_unlikely(len >= (int)sizeof(local_buf) &&
!alloc_buff)) { \
+ buflen = (size_t)len + 1U; \
+ len = -1; \
+ alloc_buff = (char *)malloc(buflen); \
+ msg = alloc_buff; \
+ if (!alloc_buff) \
+ break; \
+ } else \
+ break; \
+ } \
+\
+ /* len does not include the final \0 */ \
+ if (caa_likely(len >= 0)) { \
+ callback(__VA_ARGS__); \
+ } \
+ /*
Re: [lttng-dev] reading context fields causes syscalls
Hello Mathieu, Am Do., 20. Mai 2021 um 16:16 Uhr schrieb Mathieu Desnoyers : > > - On May 20, 2021, at 9:42 AM, Norbert Lange nolang...@gmail.com wrote: > > > Am Do., 20. Mai 2021 um 15:28 Uhr schrieb Mathieu Desnoyers > > : > >> > >> - On May 20, 2021, at 8:46 AM, Norbert Lange nolang...@gmail.com wrote: > >> > >> > Am Mi., 19. Mai 2021 um 20:52 Uhr schrieb Mathieu Desnoyers > >> > : > >> >> > >> >> - On May 19, 2021, at 8:11 AM, lttng-dev lttng-dev@lists.lttng.org > >> >> wrote: > >> >> > >> >> > Hello, > >> >> > > >> >> > Several context fields will cause a syscall atleast the first time a > >> >> > tracepoint is > >> >> > recorded. For example all of the following: > >> >> > > >> >> > `lttng add-context -c chan --userspace --type=vpid --type=vtid > >> >> > --type=procname` > >> >> > > >> >> > Each of them seems cached in TLS however, and most should never change > >> >> > after startup. > >> >> > > >> >> > As I am using Lttng over Xenomai, syscalls are strictly forbidden, I > >> >> > would like to have some function that prepares all data, which I can > >> >> > call on each thread before it switches to realtime work. > >> >> > > >> >> > Kinda similar to urcu_bp_register_thread, I'd like to have some > >> >> > `lttng_ust_warmup_thread` function that fetches the context values > >> >> > that can be cached. (urcu_bp_register_thread should be called there > >> >> > aswell) > >> >> > I considered just doing a tracepoint, but AFAIK the channel can be > >> >> > changed/configured after the process is running. So this is not robust > >> >> > enough. > >> >> > >> >> The new lttng_ust_init_thread() API in lttng-ust 2.13 would be the right > >> >> place to do this I think: > >> >> > >> >> /* > >> >> * Initialize this thread's LTTng-UST data structures. There is > >> >> * typically no need to call this, because LTTng-UST initializes its > >> >> * per-thread data structures lazily, but it should be called explicitly > >> >> * upon creation of each thread before signal handlers nesting over > >> >> * those threads use LTTng-UST tracepoints. > >> >> */ > >> >> > >> >> It would make sense that this new initialization helper also initializes > >> >> all contexts which cache the result of a system call. Considering that > >> >> contexts can be used from the filter and capture bytecode interpreter, > >> >> as > >> >> well as contexts added to channels, I think we'd need to simply > >> >> initialize > >> >> them all. Any update on that, is there an list of open points/features for lttng? Norbert ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] Feature request: dynamically load from prefix
Am Di., 5. Okt. 2021 um 20:28 Uhr schrieb Mathieu Desnoyers
:
>
> - On Jul 15, 2021, at 7:21 AM, lttng-dev lttng-dev@lists.lttng.org wrote:
>
> > Hello,
> >
> > The production rootfs should be untouched, ideally read-only,
> > for development/tests a subdirectory can be mounted (eg. /usr/local).
> > Idea is that the contents of that directory alone (and at most some
> > env variables)
> > should allow enabling development features.
> >
> > For lttng I would have wanted to add a library
> > '/usr/local/lib/libmyservice-tracepoints.so' with runpath
> > '/usr/local/lib' that would activate lttng tracing,
> > pulling in lttng libraries (ust, ust-tracepoint) from /usr/local/lib.
> >
> > There is a caveat though, unless 'libmyservice-tracepoints.so'' is
> > preloaded, the code in lttng/tracepoint.h will run constructor functions
> > to register the tracepoint probes, trying to dlopen the lttng-ust-tracepoint
> > library and fail at that because this is not in the library search paths.
> >
> > At a later time, 'libmyservice-tracepoints.so'' will be loaded, and
> > lttng-ust-tracepoint (along with lttng-ust) can be resolved. but the
> > tracepoints are not registered.
> >
> > So I guess what I would need is to either retrigger the registration
> > of tracepoints
> > (likely complicated with static and weak symbols potentially causing a
> > mess), or
> > redirect the dlopen function.
> > Useful would be either try to find the library in /usr/local/lib or
> > use '/usr/local/lib/libmyservice-tracepoints.so''
> > instead of lttng-ust-tracepoint (both have (dis)advantages).
> >
> > At any rate, I would welcome some customization macro.
>
> I'm currently working on improvements to the reporting of such scenario.
>
> See:
>
> https://review.lttng.org/c/lttng-ust/+/6480 tracepoints: print debug message
> when lttng-ust-tracepoint.so is not found
> https://review.lttng.org/c/lttng-ust/+/6484 tracepoints: increase dlopen
> failure message level from debug to critical
>
> With this in place, it should be easier for a lttng end-user to figure out
> that
> liblttng-ust-tracepoint.so cannot be found by dlopen() because it is not in
> the
> system's library search path.
>
> From that point, what is wrong with requesting the user to add the path
> towards
> liblttng-ust-tracepoint.so to the environment variable LD_LIBRARY_PATH when
> running
> the application ?
Not feasible if this is a read-only rootfs, service configuration cant
be modified.
the idea is to have some trickery to allow /usr/local mounted to a NFS
or small rw filesystem,
then drop the files (libmyservice-tracepoints.so and
liblttng-ust-tracepoint.so and services) there.
then, the app can be instructed to load
/usr/local/lib/libmyservice-tracepoints.so
/usr/local is not referenced anywhere in the rootfs and should not
affect anything,
if for ex I drop another libc.so.6 there it should not affect anything
normally running.
Ideally liblttng-ust-tracepoint.so could be loaded later and not
pulled in by the tracepoint stubs,
but I understand that this is complicated.
Any good reason not to provide some customization point like
LTTNG_TRACEPOINT_PROBE_DLOPEN
for the stuff you locally include into your build?
Would meet me half-way ;)
Norbert
>
> Thanks,
>
> Mathieu
>
> >
> > For illustration the current hack-around is following
> >
> > Norbert Lange
> >
> > #define TRACEPOINT_DEFINE
> > #define TRACEPOINT_PROBE_DYNAMIC_LINKAGE
> >
> > #include
> >
> > static inline void *s_remap_dlopen(const char *localfilename, int
> > flags, unsigned prelen) {
> >void *md = (dlopen)(localfilename + prelen, flags);
> >return md ? md : (dlopen)(localfilename, flags);
> > }
> >
> > # ideally this would be LTTNG_TRACEPOINT_PROBE_DLOPEN instead of the dlopen
> > mess
> > #define dlopen(x, y) s_remap_dlopen("/usr/local/lib/" x, y,
> > (unsigned)sizeof("/usr/local/lib/") - 1U)
> >
> > #include "trace_mytracepoints.h"
> > ___
> > lttng-dev mailing list
> > lttng-dev@lists.lttng.org
> > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] Feature request: dynamically load from prefix
Hello,
The production rootfs should be untouched, ideally read-only,
for development/tests a subdirectory can be mounted (eg. /usr/local).
Idea is that the contents of that directory alone (and at most some
env variables)
should allow enabling development features.
For lttng I would have wanted to add a library
'/usr/local/lib/libmyservice-tracepoints.so' with runpath
'/usr/local/lib' that would activate lttng tracing,
pulling in lttng libraries (ust, ust-tracepoint) from /usr/local/lib.
There is a caveat though, unless 'libmyservice-tracepoints.so'' is
preloaded, the code in lttng/tracepoint.h will run constructor functions
to register the tracepoint probes, trying to dlopen the lttng-ust-tracepoint
library and fail at that because this is not in the library search paths.
At a later time, 'libmyservice-tracepoints.so'' will be loaded, and
lttng-ust-tracepoint (along with lttng-ust) can be resolved. but the
tracepoints are not registered.
So I guess what I would need is to either retrigger the registration
of tracepoints
(likely complicated with static and weak symbols potentially causing a mess), or
redirect the dlopen function.
Useful would be either try to find the library in /usr/local/lib or
use '/usr/local/lib/libmyservice-tracepoints.so''
instead of lttng-ust-tracepoint (both have (dis)advantages).
At any rate, I would welcome some customization macro.
For illustration the current hack-around is following
Norbert Lange
#define TRACEPOINT_DEFINE
#define TRACEPOINT_PROBE_DYNAMIC_LINKAGE
#include
static inline void *s_remap_dlopen(const char *localfilename, int
flags, unsigned prelen) {
void *md = (dlopen)(localfilename + prelen, flags);
return md ? md : (dlopen)(localfilename, flags);
}
# ideally this would be LTTNG_TRACEPOINT_PROBE_DLOPEN instead of the dlopen mess
#define dlopen(x, y) s_remap_dlopen("/usr/local/lib/" x, y,
(unsigned)sizeof("/usr/local/lib/") - 1U)
#include "trace_mytracepoints.h"
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] Disabling sys_membarrier in lttng urcu
Hello,
Some old topic, see
https://lists.lttng.org/pipermail/lttng-dev/2019-November/029411.html.
(I actually thought this was solved meanwhile).
With lttng 2.13 liburcu is replicated in lttng-ust so my old custom
hack aint helping.
Aside from another crude hack, I thought about doing this:
extern int lttng_ust_urcu_has_sys_membarrier;
int setup() {
lttng_ust_urcu_has_sys_membarrier = 0;
}
this is obvious possible in my own program, but I don't know if some
lttng daemon would need to update RCU structures in shared memory that
should sync to other processes (and wont do that with sys_membarrier
in case of Xenomai threads)?
Seems safer to me to hack it out once more...
Norbert
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [PATCH lttng-ust] Improve tracef/tracelog to use the stack for small strings
Am Di., 25. Mai 2021 um 15:44 Uhr schrieb Norbert Lange :
>
> Support two common cases, one being that the resulting message is
> small enough to fit into a on-stack buffer.
> The seconds being the common 'printf("%s", "Message")' scheme.
>
> Unfortunately, iterating a va_list is destructive,
> so it has to be copied before calling vprintf.
>
> The implementation was moved to a separate file,
> used by both tracef.c and tracelog.c.
>
> Signed-off-by: Norbert Lange
> ---
> src/common/tracer.h | 2 +
> src/lib/lttng-ust-tracepoint/tracef.c | 32 ++-
> .../lttng-ust-tracepoint/tracelog-internal.h | 83 +++
> src/lib/lttng-ust-tracepoint/tracelog.c | 40 ++---
> 4 files changed, 102 insertions(+), 55 deletions(-)
> create mode 100644 src/lib/lttng-ust-tracepoint/tracelog-internal.h
>
> diff --git a/src/common/tracer.h b/src/common/tracer.h
> index 2affd6ab..8e18c9b5 100644
> --- a/src/common/tracer.h
> +++ b/src/common/tracer.h
> @@ -26,6 +26,8 @@
> #define LTTNG_RFLAG_EXTENDED RING_BUFFER_RFLAG_END
> #define LTTNG_RFLAG_END(LTTNG_RFLAG_EXTENDED << 1)
>
> +#define LTTNG_TRACE_PRINTF_BUFSIZE 512
> +
> /*
> * LTTng client type enumeration. Used by the consumer to map the
> * callbacks from its own address space.
> diff --git a/src/lib/lttng-ust-tracepoint/tracef.c
> b/src/lib/lttng-ust-tracepoint/tracef.c
> index c05c7811..92911e1d 100644
> --- a/src/lib/lttng-ust-tracepoint/tracef.c
> +++ b/src/lib/lttng-ust-tracepoint/tracef.c
> @@ -7,6 +7,7 @@
> #define _LGPL_SOURCE
> #include
> #include "common/macros.h"
> +#include "common/tracer.h"
>
> /* The tracepoint definition is public, but the provider definition is
> hidden. */
> #define LTTNG_UST_TRACEPOINT_PROVIDER_HIDDEN_DEFINITION
> @@ -15,39 +16,22 @@
> #define LTTNG_UST_TRACEPOINT_DEFINE
> #include "lttng-ust-tracef-provider.h"
>
> -static inline
> -void lttng_ust___vtracef(const char *fmt, va_list ap)
> - __attribute__((always_inline, format(printf, 1, 0)));
> -static inline
> -void lttng_ust___vtracef(const char *fmt, va_list ap)
> -{
> - char *msg;
> - const int len = vasprintf(, fmt, ap);
> -
> - /* len does not include the final \0 */
> - if (len < 0)
> - goto end;
> - lttng_ust_tracepoint_cb_lttng_ust_tracef___event(msg, len,
> - LTTNG_UST_CALLER_IP());
> - free(msg);
> -end:
> - return;
> -}
> +#include "tracelog-internal.h"
>
> void lttng_ust__vtracef(const char *fmt, va_list ap)
> __attribute__((format(printf, 1, 0)));
> void lttng_ust__vtracef(const char *fmt, va_list ap)
> {
> - lttng_ust___vtracef(fmt, ap);
> + LTTNG_UST_TRACELOG_VALIST(fmt, ap,
> + lttng_ust_tracepoint_cb_lttng_ust_tracef___event,
> + msg, len, LTTNG_UST_CALLER_IP());
> }
>
> void lttng_ust__tracef(const char *fmt, ...)
> __attribute__((format(printf, 1, 2)));
> void lttng_ust__tracef(const char *fmt, ...)
> {
> - va_list ap;
> -
> - va_start(ap, fmt);
> - lttng_ust___vtracef(fmt, ap);
> - va_end(ap);
> + LTTNG_UST_TRACELOG_VARARG(fmt,
> + lttng_ust_tracepoint_cb_lttng_ust_tracef___event,
> + msg, len, LTTNG_UST_CALLER_IP());
> }
> diff --git a/src/lib/lttng-ust-tracepoint/tracelog-internal.h
> b/src/lib/lttng-ust-tracepoint/tracelog-internal.h
> new file mode 100644
> index ..291ff27c
> --- /dev/null
> +++ b/src/lib/lttng-ust-tracepoint/tracelog-internal.h
> @@ -0,0 +1,83 @@
> +/*
> + * SPDX-License-Identifier: MIT
> + *
> + * Copyright (C) 2013-2014 Mathieu Desnoyers
> + * Copyright (C) 2021 Norbert Lange
> + *
> + * Shared helper macro for tracelog and tracef
> + */
> +
> +#define LTTNG_UST_TRACELOG_VARARG(fmt, callback, ...) \
> + va_list ap; \
> + char local_buf[LTTNG_TRACE_PRINTF_BUFSIZE]; \
> + int len; \
> + char *msg = local_buf; \
> + size_t buflen = sizeof(local_buf); \
> + char *alloc_buff = NULL; \
> +\
> + if (caa_unlikely(fmt[0] == '%' && fmt[1] == 's' && fmt[2] == '\0')) {
> \
> + va_start(ap, fmt); \
> + msg = va_arg(ap, char *); \
> + va_end(ap); \
> + len = strlen(msg); \
> + } else \
> + for(;;) { \
> + va_start(ap, fmt); \
> + len = vsnprintf(msg, buflen, fmt, ap); \
> + va_end(ap); \
> +\
> + if (caa_unlikely(len >= (int)sizeof(local_buf) &&
> !alloc_buff)) { \
> + buflen = (size_t)len + 1U; \
> + len = -1; \
> + alloc_buff = (char *)malloc(buflen); \
> + msg = alloc_buff; \
> + if (!alloc_buff) \
> + break; \
> + } else
[lttng-dev] [PATCH lttng-ust] Improve tracef/tracelog to use the stack for small strings
Support two common cases, one being that the resulting message is
small enough to fit into a on-stack buffer.
The seconds being the common 'printf("%s", "Message")' scheme.
Unfortunately, iterating a va_list is destructive,
so it has to be copied before calling vprintf.
The implementation was moved to a separate file,
used by both tracef.c and tracelog.c.
Signed-off-by: Norbert Lange
---
src/common/tracer.h | 2 +
src/lib/lttng-ust-tracepoint/tracef.c | 32 ++-
.../lttng-ust-tracepoint/tracelog-internal.h | 83 +++
src/lib/lttng-ust-tracepoint/tracelog.c | 40 ++---
4 files changed, 102 insertions(+), 55 deletions(-)
create mode 100644 src/lib/lttng-ust-tracepoint/tracelog-internal.h
diff --git a/src/common/tracer.h b/src/common/tracer.h
index 2affd6ab..8e18c9b5 100644
--- a/src/common/tracer.h
+++ b/src/common/tracer.h
@@ -26,6 +26,8 @@
#define LTTNG_RFLAG_EXTENDED RING_BUFFER_RFLAG_END
#define LTTNG_RFLAG_END(LTTNG_RFLAG_EXTENDED << 1)
+#define LTTNG_TRACE_PRINTF_BUFSIZE 512
+
/*
* LTTng client type enumeration. Used by the consumer to map the
* callbacks from its own address space.
diff --git a/src/lib/lttng-ust-tracepoint/tracef.c
b/src/lib/lttng-ust-tracepoint/tracef.c
index c05c7811..92911e1d 100644
--- a/src/lib/lttng-ust-tracepoint/tracef.c
+++ b/src/lib/lttng-ust-tracepoint/tracef.c
@@ -7,6 +7,7 @@
#define _LGPL_SOURCE
#include
#include "common/macros.h"
+#include "common/tracer.h"
/* The tracepoint definition is public, but the provider definition is hidden.
*/
#define LTTNG_UST_TRACEPOINT_PROVIDER_HIDDEN_DEFINITION
@@ -15,39 +16,22 @@
#define LTTNG_UST_TRACEPOINT_DEFINE
#include "lttng-ust-tracef-provider.h"
-static inline
-void lttng_ust___vtracef(const char *fmt, va_list ap)
- __attribute__((always_inline, format(printf, 1, 0)));
-static inline
-void lttng_ust___vtracef(const char *fmt, va_list ap)
-{
- char *msg;
- const int len = vasprintf(, fmt, ap);
-
- /* len does not include the final \0 */
- if (len < 0)
- goto end;
- lttng_ust_tracepoint_cb_lttng_ust_tracef___event(msg, len,
- LTTNG_UST_CALLER_IP());
- free(msg);
-end:
- return;
-}
+#include "tracelog-internal.h"
void lttng_ust__vtracef(const char *fmt, va_list ap)
__attribute__((format(printf, 1, 0)));
void lttng_ust__vtracef(const char *fmt, va_list ap)
{
- lttng_ust___vtracef(fmt, ap);
+ LTTNG_UST_TRACELOG_VALIST(fmt, ap,
+ lttng_ust_tracepoint_cb_lttng_ust_tracef___event,
+ msg, len, LTTNG_UST_CALLER_IP());
}
void lttng_ust__tracef(const char *fmt, ...)
__attribute__((format(printf, 1, 2)));
void lttng_ust__tracef(const char *fmt, ...)
{
- va_list ap;
-
- va_start(ap, fmt);
- lttng_ust___vtracef(fmt, ap);
- va_end(ap);
+ LTTNG_UST_TRACELOG_VARARG(fmt,
+ lttng_ust_tracepoint_cb_lttng_ust_tracef___event,
+ msg, len, LTTNG_UST_CALLER_IP());
}
diff --git a/src/lib/lttng-ust-tracepoint/tracelog-internal.h
b/src/lib/lttng-ust-tracepoint/tracelog-internal.h
new file mode 100644
index ..291ff27c
--- /dev/null
+++ b/src/lib/lttng-ust-tracepoint/tracelog-internal.h
@@ -0,0 +1,83 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright (C) 2013-2014 Mathieu Desnoyers
+ * Copyright (C) 2021 Norbert Lange
+ *
+ * Shared helper macro for tracelog and tracef
+ */
+
+#define LTTNG_UST_TRACELOG_VARARG(fmt, callback, ...) \
+ va_list ap; \
+ char local_buf[LTTNG_TRACE_PRINTF_BUFSIZE]; \
+ int len; \
+ char *msg = local_buf; \
+ size_t buflen = sizeof(local_buf); \
+ char *alloc_buff = NULL; \
+\
+ if (caa_unlikely(fmt[0] == '%' && fmt[1] == 's' && fmt[2] == '\0')) { \
+ va_start(ap, fmt); \
+ msg = va_arg(ap, char *); \
+ va_end(ap); \
+ len = strlen(msg); \
+ } else \
+ for(;;) { \
+ va_start(ap, fmt); \
+ len = vsnprintf(msg, buflen, fmt, ap); \
+ va_end(ap); \
+\
+ if (caa_unlikely(len >= (int)sizeof(local_buf) &&
!alloc_buff)) { \
+ buflen = (size_t)len + 1U; \
+ len = -1; \
+ alloc_buff = (char *)malloc(buflen); \
+ msg = alloc_buff; \
+ if (!alloc_buff) \
+ break; \
+ } else \
+ break; \
+ } \
+\
+ /* len does not include the final \0 */ \
+ if (caa_likely(len >= 0)) { \
+ callback(__VA_ARGS__); \
+ } \
+ /* Dont call a potentially instrumented forbidden free needlessly. */ \
+ if
Re: [lttng-dev] [PATCH lttng-ust] Improve tracelog handling, reduce exported functions
Am Do., 20. Mai 2021 um 19:18 Uhr schrieb Mathieu Desnoyers : > > > > - On May 20, 2021, at 12:51 PM, Norbert Lange nolang...@gmail.com wrote: > > > Am Do., 20. Mai 2021 um 18:25 Uhr schrieb Mathieu Desnoyers > > : > >> > >> - On May 20, 2021, at 11:54 AM, Norbert Lange nolang...@gmail.com > >> wrote: > >> [...] > >> > >> >> What prevents you from linking against lttng-ust.so again ? > >> > > >> > I did not poke around enough with Lttng to be confident it wont have > >> > side effects, > >> > I really don't want it active in production. It doesn't seem there is > >> > much public knowledge with Xenomai either. > >> > lttng-ust.so will spawn threads, lttng-ust-tracepoint.so is mostly > >> > passive, > >> > >> There is indeed a split between instrumentation and runtime threads done > >> with lttng-ust-tracepoint.so vs lttng-ust.so. > >> > >> I understand that this split is missing for tracelog and tracef, and > >> would be a good thing to have. > >> > >> I would be interested to move the tracelog and tracef implementation > >> from liblttng-ust.so to liblttng-ust-tracepoint.so, even this late > >> in the -rc cycle, because all users of tracelog/tracef need to link > >> against liblttng-ust-tracepoint.so anyway. So moving these symbols > >> should not affect anyone. > >> > >> Can you give it a try and let me know if it works for you ? > > > > Will take some time, whats the timeframe you need for feedback? > > Here is the tentative commit: > > https://review.lttng.org/c/lttng-ust/+/5927 Move tracef/tracelog symbols to > liblttng-ust-tracepoint.so > Make a own thread for this? I testet this, but get errors as liblttng-ust-tracepoint.so depends on symbols from liblttng-ust.so. /usr/lib/gcc/x86_64-linux-gnu/10/../../../../x86_64-linux-gnu/bin/ld: /tmp/opt/hipase2/buildroot-acpu/host/x86_64-buildroot-linux-gnu/sysroot/lib/../lib64/liblttng-ust-tracepoint.so: undefined reference to `lttng_ust_probe_register' /usr/lib/gcc/x86_64-linux-gnu/10/../../../../x86_64-linux-gnu/bin/ld: /tmp/opt/hipase2/buildroot-acpu/host/x86_64-buildroot-linux-gnu/sysroot/lib/../lib64/liblttng-ust-tracepoint.so: undefined reference to `lttng_ust_probe_unregister' ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] LTTng - Xenomai : different results between timestamp-lttng and rt_time_read()
Am Fr., 21. Mai 2021 um 12:13 Uhr schrieb MONTET Julien : > > Hello Mathieu, Norbert and Jan, > > Thank you for all of your explainations and the overview of the system. > No I didn't change the ipipe patch for the vDSO, I may try this. > If I have correctly understood, this patch prevents Cobalt from entering in a > deadlock when the kernel is using the vDSO and the program interrupts the > kernel at the same time. On which kernel does it word (aroubd 4.19) ? > I currently try to avoid kernel 5.4 because I remember I faced some boot > issues (but it is on another topic). That patch was for 4.19 AFAIR, but its specific to x86. The Linux kernel cleaned up the vdso handling to have a common base with some 5.x version, but back then its been separate for each arch > > Here the issues i faced (drawn on TraceCompass). Are these the deadlocks we > are talking about ? > https://postimg.cc/BP4G3bF0 (on 11:02:56:380) > https://postimg.cc/q6wHvrcC Nope, if you get such a deadlock, then your only hope is Xenomai's Watchdog killing the process. It should happen very rarely (but thats not an argument if your software should run for years). Norbert ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [PATCH lttng-ust] Improve tracelog handling, reduce exported functions
Am Do., 20. Mai 2021 um 19:18 Uhr schrieb Mathieu Desnoyers : > > > > - On May 20, 2021, at 12:51 PM, Norbert Lange nolang...@gmail.com wrote: > > > Am Do., 20. Mai 2021 um 18:25 Uhr schrieb Mathieu Desnoyers > > : > >> > >> - On May 20, 2021, at 11:54 AM, Norbert Lange nolang...@gmail.com > >> wrote: > >> [...] > >> > >> >> What prevents you from linking against lttng-ust.so again ? > >> > > >> > I did not poke around enough with Lttng to be confident it wont have > >> > side effects, > >> > I really don't want it active in production. It doesn't seem there is > >> > much public knowledge with Xenomai either. > >> > lttng-ust.so will spawn threads, lttng-ust-tracepoint.so is mostly > >> > passive, > >> > >> There is indeed a split between instrumentation and runtime threads done > >> with lttng-ust-tracepoint.so vs lttng-ust.so. > >> > >> I understand that this split is missing for tracelog and tracef, and > >> would be a good thing to have. > >> > >> I would be interested to move the tracelog and tracef implementation > >> from liblttng-ust.so to liblttng-ust-tracepoint.so, even this late > >> in the -rc cycle, because all users of tracelog/tracef need to link > >> against liblttng-ust-tracepoint.so anyway. So moving these symbols > >> should not affect anyone. > >> > >> Can you give it a try and let me know if it works for you ? > > > > Will take some time, whats the timeframe you need for feedback? > > Here is the tentative commit: > > https://review.lttng.org/c/lttng-ust/+/5927 Move tracef/tracelog symbols to > liblttng-ust-tracepoint.so Well... this is certainly an improvement. I am not completely happy though: "... users now link against liblttng-ust-tracepoint.so explicitly" My homecooked solution currently works like this: *) define the probes from with TRACEPOINT_PROBE_DYNAMIC_LINKAGE, link them in the application, together with other dynamic probes *) build a separate library with *other* tracepoints, lets call it libtracepoint.so *) don't link the application to any lttng library. Which means: 1) the application works without lttng libraries. tracepoints are no-ops 2) if available then liblttng-ust-tracepoint.so is loaded (constructor function from your headers). tracepoints are no-ops 3) if the application dlopen's libtracepoint.so and in turn liblttng-ust.so then tracepoints work. I'd lose option 1 compared to reimplementing tracelog using homecooked lttng-ust-tracelog tracepoints. So, are there any issues using that way, it seems to work fine, are there mutliple competing instances now? (I am not re-using any bit from tracelog.h, I am just after using the tracepoint definition). I mean I could dlsym all the functions, but tracelog has 1 per loglevel and really ugly long names ;) Norbert ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [PATCH lttng-ust] Improve tracelog handling, reduce exported functions
Am Do., 20. Mai 2021 um 18:25 Uhr schrieb Mathieu Desnoyers : > > - On May 20, 2021, at 11:54 AM, Norbert Lange nolang...@gmail.com wrote: > [...] > > >> What prevents you from linking against lttng-ust.so again ? > > > > I did not poke around enough with Lttng to be confident it wont have > > side effects, > > I really don't want it active in production. It doesn't seem there is > > much public knowledge with Xenomai either. > > lttng-ust.so will spawn threads, lttng-ust-tracepoint.so is mostly passive, > > There is indeed a split between instrumentation and runtime threads done > with lttng-ust-tracepoint.so vs lttng-ust.so. > > I understand that this split is missing for tracelog and tracef, and > would be a good thing to have. > > I would be interested to move the tracelog and tracef implementation > from liblttng-ust.so to liblttng-ust-tracepoint.so, even this late > in the -rc cycle, because all users of tracelog/tracef need to link > against liblttng-ust-tracepoint.so anyway. So moving these symbols > should not affect anyone. > > Can you give it a try and let me know if it works for you ? Will take some time, whats the timeframe you need for feedback? > > So Id want a dynamic tracepoint-provider than i can dlopen (so that > > the signal masks are inherited, > > I hope you dont touch them). > > The signals are all blocked for lttng-ust listener threads. We don't > modify the signal masks in the tracepoint probes. Not sure which is > the target of your question though. The first one, if i'd preloaded lttng-ust and you dont mask signals, then those could end up in the realtime threads. Every Xenomai Thread has a background Linux Thread that's idle when realtime is active, ironically making them perfect targets for signal delivery > > > > > Of course I could just remove all lttng libraries on the production > > system aswell. Still doesnt change that > > tracelog and tracef doesnt work that way. > > Would moving the tracelog/tracef implementation to liblttng-ust-tracepoint.so > solve your issues ? Yes, definitely. They should then work identically to other tracepoints with TRACEPOINT_PROBE_DYNAMIC_LINKAGE. > > > > > I implemented my own tracelog/tracef using the normal lttng > > tracepoints for now, they totally break on source level with 2.13 > > aswell ;) > > is it ok if I do this to access them: > > > > #define TRACEPOINT_DEFINE > > #define TRACEPOINT_PROBE_DYNAMIC_LINKAGE > > // 2.12 > > // #include > > // #include > > // 2.13 > > #include > > #include > > > > ie. I would load lttng-ust.so later and can then use those tracepoints. > > Reimplementing the tracelog/tracef providers is not an intended use-case. > I'd very much prefer if we move their implementation to > liblttng-ust-tracepoint.so. FWIW it works, and ill use it for a while (cant just swap out libraries everywhere now). Of course Id love a upstream solution. Norbert ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] 2.13-rc2 fails to build with buildroot crosscompiler
Am Do., 20. Mai 2021 um 16:37 Uhr schrieb Michael Jeanson : > > On 2021-05-20 9:52 a.m., Norbert Lange via lttng-dev wrote: > > Hello, > > > > many tests fail to build, apparently because transitive dependencies > > are not found. > > I managed to patch out building the test sub-directory, at which > > points the errors are gone, > > I dont know how to fix it with automake, seems like > > /tmp/ZBuild/build/lttng-libust-2.13.0-rc2/src/lib/lttng-ust/.libs > > should be added to library search paths. > > > > Norbert > > The libtool integration with autotools should be handling these transitive > dependencies but somehow doesn't seem to work in your environment. A > workaround could be to add the liblttng-ust-common.la file to all the test > file:///home/noppl/git/buildroot/0001-package-lttng-bump-to-2.13rc2-WIP.patch > binaries _LDADD where liblttng-ust.la is already present, for example: > > ust_fields_compatapi1_LDADD = \ > $(top_builddir)/src/lib/lttng-ust/liblttng-ust.la \ > $(top_builddir)/src/lib/lttng-ust-common/liblttng-ust-common.la \ > $(DL_LIBS) > > Can you check if this works? I suppose it would, but there are many many of these errors also by linking libraries build in the test directory, would cost some time and I am not able to triage automake/libtool issues. Is that the solution upstream wants to use? I attached a patch for https://buildroot.org/ to pick the current lttng rc2. using buildroot is easy (but timeconsuming if you build the cross-compiler aswell): make O=/tmp/build defconfig make O=/tmp/build menuconfig Pick your hosts/prefered architecture in Target options In toolchain menu pick kernel headers + c library type (glibc for me) Enable: Target packages -> Libraries -> Other -> lttng-libust Target packages -> Debugging, profiling and benchmark -> lttng-tools Then make O=/tmp/build Norbert From 0e5266d826e7fcbdd3e09977f58bfff82e8d7476 Mon Sep 17 00:00:00 2001 From: Norbert Lange Date: Thu, 20 May 2021 18:11:44 +0200 Subject: [PATCH] package/lttng: bump to 2.13rc2 (WIP) --- package/lttng-libust/lttng-libust.hash | 4 ++-- package/lttng-libust/lttng-libust.mk | 2 +- package/lttng-tools/lttng-tools.hash | 4 ++-- package/lttng-tools/lttng-tools.mk | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/package/lttng-libust/lttng-libust.hash b/package/lttng-libust/lttng-libust.hash index 40bd870e86..2f58db2bf5 100644 --- a/package/lttng-libust/lttng-libust.hash +++ b/package/lttng-libust/lttng-libust.hash @@ -1,5 +1,5 @@ -# From https://lttng.org/files/lttng-ust/lttng-ust-2.12.1.tar.bz2.sha256 -sha256 48a3948b168195123a749d22818809bd25127bb5f1a66458c3c012b210d2a051 lttng-ust-2.12.1.tar.bz2 +# From https://lttng.org/files/lttng-ust/lttng-ust-2.13.0-rc2.tar.bz2.sha256 +sha256 51a2bd2e7cb15b4fb110fc6ceeb118256688c4b1da1dadfabdb1de9f079fd8cf lttng-ust-2.13.0-rc2.tar.bz2 # Hash for license file sha256 74125a84c2166300776980166e29de40d5f98d1a75e487f0bbc0c03b4cd2342e COPYING diff --git a/package/lttng-libust/lttng-libust.mk b/package/lttng-libust/lttng-libust.mk index 608e8781b1..d99577504a 100644 --- a/package/lttng-libust/lttng-libust.mk +++ b/package/lttng-libust/lttng-libust.mk @@ -5,7 +5,7 @@ LTTNG_LIBUST_SITE = http://lttng.org/files/lttng-ust -LTTNG_LIBUST_VERSION = 2.12.1 +LTTNG_LIBUST_VERSION = 2.13.0-rc2 LTTNG_LIBUST_SOURCE = lttng-ust-$(LTTNG_LIBUST_VERSION).tar.bz2 LTTNG_LIBUST_LICENSE = LGPL-2.1, MIT (system headers), GPL-2.0 (liblttng-ust-ctl/ustctl.c used by lttng-sessiond) LTTNG_LIBUST_LICENSE_FILES = COPYING diff --git a/package/lttng-tools/lttng-tools.hash b/package/lttng-tools/lttng-tools.hash index a94ecc4a35..d00ab133c7 100644 --- a/package/lttng-tools/lttng-tools.hash +++ b/package/lttng-tools/lttng-tools.hash @@ -1,5 +1,5 @@ -# From https://lttng.org/files/lttng-tools/lttng-tools-2.12.3.tar.bz2.sha256 -sha256 2890da230edd523fcf497e9eb28133b7606d64fa01bcbffadbfcba42104db153 lttng-tools-2.12.3.tar.bz2 +# From https://lttng.org/files/lttng-tools/lttng-tools-2.13.0-rc2.tar.bz2.sha256 +sha256 5c26d39634adb00e8e953c3caf4dfcb9ba31c510cf21395629b741fa338e1b08 lttng-tools-2.13.0-rc2.tar.bz2 # Locally computed sha256 068e55c7dbe597400199aee75ac5e71bdb2ca88c4c9a4cfa8e1fbc61f933eda5 LICENSE diff --git a/package/lttng-tools/lttng-tools.mk b/package/lttng-tools/lttng-tools.mk index 8789ded333..f1b1c7217b 100644 --- a/package/lttng-tools/lttng-tools.mk +++ b/package/lttng-tools/lttng-tools.mk @@ -4,7 +4,7 @@ # -LTTNG_TOOLS_VERSION = 2.12.3 +LTTNG_TOOLS_VERSION = 2.13.0-rc2 LTTNG_TOOLS_SITE = https://lttng.org/files/lttng-tools LTTNG_TOOLS_SOURCE = lttng-tools-$(LTTNG_TOOLS_VERSION).tar.bz2 LTTNG_TOOLS_INSTALL_ST
Re: [lttng-dev] [PATCH lttng-ust] Improve tracelog handling, reduce exported functions
Am Do., 20. Mai 2021 um 17:21 Uhr schrieb Mathieu Desnoyers : > > - On May 20, 2021, at 10:57 AM, Norbert Lange nolang...@gmail.com wrote: > > > Am Do., 20. Mai 2021 um 16:19 Uhr schrieb Mathieu Desnoyers > > : > >> > >> - On May 20, 2021, at 8:18 AM, lttng-dev lttng-dev@lists.lttng.org > >> wrote: > >> > >> > Instead of creating functions for each loglevel, simply pass the > >> > callback as argument. > >> > > >> > Further pack all preprocessor information into a struct that > >> > the compiler already can prepare. > >> > >> This introduces an ABI break too late in the cycle. > > > > So 2.14 would be the next chance I guess > > No. The original ABI was introduced about 10 years ago with lttng-ust 2.0, > and lttng-ust 2.13 introduces the first ABI break since. I don't > plan on doing any ABI break in lttng-ust in the foreseeable future. > > ABI breaks require that our users recompile all their instrumented > applications, which is really cumbersome for large software deployments. > We don't break ABI lightly. Yeah, I understand. > >> Also, I'm not so keen on adding an indirect call on the fast-path > >> when it's not absolutely needed. > > > > Code seems pretty similar: https://godbolt.org/z/oK1WhWqGT > > By fast-path, I also mean: > > +(*callback)(source->file, source->line, source->func, msg, len, > +LTTNG_UST_CALLER_IP()); > > Which introduces an indirect call which needs to be taken when tracing > is active. The worst thing is that it would tax branch-predictors. Indirect jumps aren't that horrible, and if you have public interpose-able ELF symbols you have more of them than you might know... And that's a function that calls a printf variant, and did alloc memory. > >> What is wrong with having one symbol per loglevel ? > > > > Macro-magic is cumbersome to edit, more code, more relocations. > > If it was still time for ABI breaks, I would be tempted to consider it > especially given that tracelog and tracef are not expected to be "high-speed", > but now is too late for breaking ABI. > > > > > Easier to adapt aswell, could roll my own tracelog functions while > > using lttng_ust__tracelog_printf (started soind that as I don't want > > to link to lttng-ust.so) > > What prevents you from linking against lttng-ust.so again ? I did not poke around enough with Lttng to be confident it wont have side effects, I really don't want it active in production. It doesn't seem there is much public knowledge with Xenomai either. lttng-ust.so will spawn threads, lttng-ust-tracepoint.so is mostly passive, So Id want a dynamic tracepoint-provider than i can dlopen (so that the signal masks are inherited, I hope you dont touch them). Of course I could just remove all lttng libraries on the production system aswell. Still doesnt change that tracelog and tracef doesnt work that way. I implemented my own tracelog/tracef using the normal lttng tracepoints for now, they totally break on source level with 2.13 aswell ;) is it ok if I do this to access them: #define TRACEPOINT_DEFINE #define TRACEPOINT_PROBE_DYNAMIC_LINKAGE // 2.12 // #include // #include // 2.13 #include #include ie. I would load lttng-ust.so later and can then use those tracepoints. Norbert ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] LTTng - Xenomai : different results between timestamp-lttng and rt_time_read()
Am Do., 20. Mai 2021 um 17:09 Uhr schrieb Mathieu Desnoyers
:
>
> - On May 20, 2021, at 9:56 AM, Mathieu Desnoyers
> mathieu.desnoy...@efficios.com wrote:
>
> > - On May 20, 2021, at 9:54 AM, lttng-dev lttng-dev@lists.lttng.org
> > wrote:
> >
> >> - On May 20, 2021, at 5:11 AM, lttng-dev lttng-dev@lists.lttng.org
> >> wrote:
> >>
> >>> Am Do., 20. Mai 2021 um 10:28 Uhr schrieb MONTET Julien
> >>> :
>
> Hi Norbert,
>
> Thank you for your answer !
>
> Yes, I am using a Xenomai cobalt - xenomai is 3.1
> cat /proc/xenomai/version => 3.1
>
> After the installation, I tested "test tools" in /proc/xenomai/ and it
> worked
> nice.
> >>>
> >>> Just asked to make sure, thought the scripts usual add some -xeno tag
> >>> to the kernel version.
> >>>
> What do you mean by "it might deadlock really good" ?
> >>>
> >>> clock_gettime will either use a syscall (kills realtime always) or is
> >>> optimized via VDSO (which very likely is your case).
> >>>
> >>> What happens is that the kernel will take a spinlock, then write new
> >>> values, then releases the spinlock.
> >>> your program will aswell spin (but just to see if the spinlock is
> >>> free), read the values and interpolates them.
> >>>
> >>> But if your program interrupts the kernel while the kernel holds the
> >>> lock (all on the same cpu core), then it will spin forever and the
> >>> kernel will never execute.
> >>
> >> Just one clarification: the specific locking strategy used by the
> >> Linux kernel monotonic clock vDSO is a "seqlock", where the kernel
> >> sets a bit which keeps concurrent readers looping until they observe
> >
> > When I say "sets a bit", I actually mean "increment a sequence counter",
> > and readers observe either odd or even state, thus knowing whether
> > they need to retry, and whether the value read before/after reading
> > the data structure changed.
>
> Looking again at the Linux kernel's kernel/time/vsyscall.c implementation
> of vdso_update_{begin,end}, I notice that interrupts are disabled across
> the entire update. So I understand that the Interrupt pipeline (I-pipe)
> interrupt gets delivered even when the kernel disables interrupts. Did
> you consider modifying the I-pipe kernel patch to change the vdso update so
> it updates the vdso from within an I-pipe virq handler ?
Yes, I did use an non-upstreamed patch for a while to get things in order:
https://www.xenomai.org/pipermail/xenomai/2018-December/040134.html
I would prefer just a NMI safe source that might jump back a bit, no matter how.
> AFAIU this would allow Xenomai userspace to use the Linux kernel vDSO
> clock sources.
The Xenomai folks are trying to get their next-gen abstraction "dovetail" closer
coupled to the kernel, AFAIR their will be VDSO support and
unification of the clock sources.
Still need to get stuff running today =)
Norbert
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [PATCH lttng-ust] Improve tracelog handling, reduce exported functions
Am Do., 20. Mai 2021 um 16:19 Uhr schrieb Mathieu Desnoyers : > > - On May 20, 2021, at 8:18 AM, lttng-dev lttng-dev@lists.lttng.org wrote: > > > Instead of creating functions for each loglevel, simply pass the > > callback as argument. > > > > Further pack all preprocessor information into a struct that > > the compiler already can prepare. > > This introduces an ABI break too late in the cycle. So 2.14 would be the next chance I guess > Also, I'm not so keen on adding an indirect call on the fast-path > when it's not absolutely needed. Code seems pretty similar: https://godbolt.org/z/oK1WhWqGT > What is wrong with having one symbol per loglevel ? Macro-magic is cumbersome to edit, more code, more relocations. Easier to adapt aswell, could roll my own tracelog functions while using lttng_ust__tracelog_printf (started soind that as I don't want to link to lttng-ust.so) Norbert ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] 2.13-rc2 fails to build with buildroot crosscompiler
Hello, many tests fail to build, apparently because transitive dependencies are not found. I managed to patch out building the test sub-directory, at which points the errors are gone, I dont know how to fix it with automake, seems like /tmp/ZBuild/build/lttng-libust-2.13.0-rc2/src/lib/lttng-ust/.libs should be added to library search paths. Norbert bin/bash ../../../../libtool --tag=CC --mode=link /tmp/ZBuild/host/bin/x86_64-linux-gnu-gcc -Werror=old-style-definition -DLTTNG_UST_COMPAT_API_VERSION=1 -fno-strict-aliasing -Wall -Wextra -Wmissing-prototypes -Wmissing-declarations -Wnull-dereference -Wundef -Wshadow -Wjump-misses-init -Wsuggest-attribute=format -Wnested-externs -Wwrite-strings -Wformat=2 -Wstrict-aliasing -Wmissing-noreturn -Winit-self -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wno-sign-compare -Wno-missing-field-initializers -Wno-null-dereference -Wold-style-definition -Wstrict-prototypes -pthread -D_FILE_OFFSET_BITS=64 -Os -D_FORTIFY_SOURCE=1-o ust-fields-compatapi1 ust_fields_compatapi1-ust-fields.o ust_fields_compatapi1-tp.o ../../../../src/lib/lttng-ust/liblttng-ust.la -ldl libtool: link: /tmp/ZBuild/host/bin/x86_64-linux-gnu-gcc -Werror=old-style-definition -DLTTNG_UST_COMPAT_API_VERSION=1 -fno-strict-aliasing -Wall -Wextra -Wmissing-prototypes -Wmissing-declarations -Wnull-dereference -Wundef -Wshadow -Wjump-misses-init -Wsuggest-attribute=format -Wnested-externs -Wwrite-strings -Wformat=2 -Wstrict-aliasing -Wmissing-noreturn -Winit-self -Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wno-sign-compare -Wno-missing-field-initializers -Wno-null-dereference -Wold-style-definition -Wstrict-prototypes -pthread -D_FILE_OFFSET_BITS=64 -Os -D_FORTIFY_SOURCE=1 -o ust-fields-compatapi1 ust_fields_compatapi1-ust-fields.o ust_fields_compatapi1-tp.o ../../../../src/lib/lttng-ust/.libs/liblttng-ust.so -ldl -pthread -Wl,-rpath -Wl,/tmp/ZBuild/build/lttng-libust-2.13.0-rc2/src/lib/lttng-ust/.libs x86_64-linux-gnu/bin/ld: warning: liblttng-ust-common.so.1, needed by ../../../src/lib/lttng-ust/.libs/liblttng-ust.so, not found (try using -rpath or -rpath-link) x86_64-linux-gnu/bin/ld: warning: liblttng-ust-tracepoint.so.1, needed by ../../../src/lib/lttng-ust/.libs/liblttng-ust.so, not found (try using -rpath or -rpath-link) ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [PATCH] Avoid using the heap for small strings with tracef/tracelog
Am Do., 20. Mai 2021 um 15:33 Uhr schrieb Mathieu Desnoyers : > > - On May 20, 2021, at 8:20 AM, Norbert Lange nolang...@gmail.com wrote: > > > This patch was intended for 2.12, no src/common/tracer.h there. > > You should post feature patches against the master branch. Or if you just > want to send a RFC, and you work on an older branch, please state that the > patch is RFC and which branch the patch is against, but that work won't > be merged unless it's rebased against master. Yeah, I read the contributing guide since then, sorry =) > > Also this patch is brocken, as a va_list cant be iterated twice. > > Right. But you could easily do: > > va_start() [ first use ] va_end() > then > va_start() [ second use ] va_end(), right ? New patch vs master does this. Norbert ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] reading context fields causes syscalls
Am Do., 20. Mai 2021 um 15:28 Uhr schrieb Mathieu Desnoyers
:
>
> - On May 20, 2021, at 8:46 AM, Norbert Lange nolang...@gmail.com wrote:
>
> > Am Mi., 19. Mai 2021 um 20:52 Uhr schrieb Mathieu Desnoyers
> > :
> >>
> >> - On May 19, 2021, at 8:11 AM, lttng-dev lttng-dev@lists.lttng.org
> >> wrote:
> >>
> >> > Hello,
> >> >
> >> > Several context fields will cause a syscall atleast the first time a
> >> > tracepoint is
> >> > recorded. For example all of the following:
> >> >
> >> > `lttng add-context -c chan --userspace --type=vpid --type=vtid
> >> > --type=procname`
> >> >
> >> > Each of them seems cached in TLS however, and most should never change
> >> > after startup.
> >> >
> >> > As I am using Lttng over Xenomai, syscalls are strictly forbidden, I
> >> > would like to have some function that prepares all data, which I can
> >> > call on each thread before it switches to realtime work.
> >> >
> >> > Kinda similar to urcu_bp_register_thread, I'd like to have some
> >> > `lttng_ust_warmup_thread` function that fetches the context values
> >> > that can be cached. (urcu_bp_register_thread should be called there
> >> > aswell)
> >> > I considered just doing a tracepoint, but AFAIK the channel can be
> >> > changed/configured after the process is running. So this is not robust
> >> > enough.
> >>
> >> The new lttng_ust_init_thread() API in lttng-ust 2.13 would be the right
> >> place to do this I think:
> >>
> >> /*
> >> * Initialize this thread's LTTng-UST data structures. There is
> >> * typically no need to call this, because LTTng-UST initializes its
> >> * per-thread data structures lazily, but it should be called explicitly
> >> * upon creation of each thread before signal handlers nesting over
> >> * those threads use LTTng-UST tracepoints.
> >> */
> >>
> >> It would make sense that this new initialization helper also initializes
> >> all contexts which cache the result of a system call. Considering that
> >> contexts can be used from the filter and capture bytecode interpreter, as
> >> well as contexts added to channels, I think we'd need to simply initialize
> >> them all.
> >
> > Yeah, just figured that it doesnt help at all if I do a tracepoint, as
> > it might just be disabled ;)
> > lttng_ust_init_thread() sounds right for that, maybe add one or 2 arguments
> > for
> > stuff you want initialized / dont want initialized over the default.
> >
> > I take that the downside of eager initialization is potentially wasted
> > resources (now ignoring any one-time runtime cost).
>
> I would not want to introduce too much coupling between the application and
> the tracer though. The public API I've added for the 2.13 release cycle takes
> no argument, and I'm not considering changing that at this stage (we are
> already
> at -rc2, so we're past the API freeze).
Ok, figured if that's preferred then nows the last chance
>
> I'd be open to adding an extra API with a different purpose though. Currently
> lttng_ust_init_thread is meant to initialize per-thread data structures for
> tracing signal handlers.
>
> Your use-case is different: you aim at tracing from a context which cannot
> issue system calls. Basically, any attempt to issue a system call from that
> thread after this is a no-go. I would be tempted to introduce something like
> "lttng_ust_{set,clear}_thread_no_syscall" or such, which would have the
> following
> effects when set:
No systemcalls and no clock_gettime().
>
> * Force immediate initialization of all thread's cached context information,
Definitely needed (adding context is often needed I guess)
> * Set a TLS variable flag indicating that the tracer should not do any system
> call whatsoever. The tracer could either use dummy data (zeroes), log an
> error,
> or abort() the process if a thread in no_syscall mode attempts to issue a
> system
> call. This could be dynamically selected by a new environment variable.
How this works is than Xenomai will generate a synchronous signal,
which as default aborts. So fallbacks are nice, but error handling
isn't necessary.
Somewhat offtopic, but why is lltng not using __thread for TLS access,
usually I only see this for really old stuff?
> * Prevent threads in no_syscall mode from calling the write() system call on
> sub-buffer switch (of course the read-timer channel option is preferred).
Yeah, that was part of the last discussion. What would happen without
write notification?
Bufferstate is polled elsewhere too, or will it just be full forever?
Come to think of it, maybe it would be better to add some form of
"tags" to software,
(like a defined symbol or ELF .note section) which could prevent
processes to be traced
if in the wrong mode (no read-timer), or change what work the
lttng_ust_init_thread function
does.
Norbert
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] reading context fields causes syscalls
Am Mi., 19. Mai 2021 um 20:52 Uhr schrieb Mathieu Desnoyers : > > - On May 19, 2021, at 8:11 AM, lttng-dev lttng-dev@lists.lttng.org wrote: > > > Hello, > > > > Several context fields will cause a syscall atleast the first time a > > tracepoint is > > recorded. For example all of the following: > > > > `lttng add-context -c chan --userspace --type=vpid --type=vtid > > --type=procname` > > > > Each of them seems cached in TLS however, and most should never change > > after startup. > > > > As I am using Lttng over Xenomai, syscalls are strictly forbidden, I > > would like to have some function that prepares all data, which I can > > call on each thread before it switches to realtime work. > > > > Kinda similar to urcu_bp_register_thread, I'd like to have some > > `lttng_ust_warmup_thread` function that fetches the context values > > that can be cached. (urcu_bp_register_thread should be called there > > aswell) > > I considered just doing a tracepoint, but AFAIK the channel can be > > changed/configured after the process is running. So this is not robust > > enough. > > The new lttng_ust_init_thread() API in lttng-ust 2.13 would be the right > place to do this I think: > > /* > * Initialize this thread's LTTng-UST data structures. There is > * typically no need to call this, because LTTng-UST initializes its > * per-thread data structures lazily, but it should be called explicitly > * upon creation of each thread before signal handlers nesting over > * those threads use LTTng-UST tracepoints. > */ > > It would make sense that this new initialization helper also initializes > all contexts which cache the result of a system call. Considering that > contexts can be used from the filter and capture bytecode interpreter, as > well as contexts added to channels, I think we'd need to simply initialize > them all. Yeah, just figured that it doesnt help at all if I do a tracepoint, as it might just be disabled ;) lttng_ust_init_thread() sounds right for that, maybe add one or 2 arguments for stuff you want initialized / dont want initialized over the default. I take that the downside of eager initialization is potentially wasted resources (now ignoring any one-time runtime cost). Norbert ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] [PATCH] Avoid using the heap for small strings with tracef/tracelog
Am Mi., 19. Mai 2021 um 21:00 Uhr schrieb Mathieu Desnoyers
:
>
> - On May 19, 2021, at 12:56 PM, lttng-dev lttng-dev@lists.lttng.org wrote:
>
> > Try to use vsnprintf with a 512 Byte buffer on the Stack,
> > if that fails allocate a larger one.
>
> I agree with the approach.
>
> Can we move the hardcoded "512" to a #define within src/common/tracer.h ?
>
> Thanks,
>
> Mathieu
>
> >
> > Signed-off-by: Norbert Lange
> > ---
> > liblttng-ust/tracef.c | 13 ++---
> > liblttng-ust/tracelog.c | 12 +---
> > 2 files changed, 19 insertions(+), 6 deletions(-)
> >
> > diff --git a/liblttng-ust/tracef.c b/liblttng-ust/tracef.c
> > index ea98e43e..18c29e25 100644
> > --- a/liblttng-ust/tracef.c
> > +++ b/liblttng-ust/tracef.c
> > @@ -32,17 +32,24 @@
> > void _lttng_ust_tracef(const char *fmt, ...)
> > {
> > va_list ap;
> > - char *msg;
> > + char local_buf[512];
> > + char *msg = local_buf;
> > int len;
> >
> > va_start(ap, fmt);
> > - len = vasprintf(, fmt, ap);
> > + len = vsnprintf(local_buf, sizeof(local_buf), fmt, ap);
> > + if (len >= sizeof(local_buf)) {
> > + msg = (char *)malloc(len + 1);
> > + len = msg ? vsnprintf(msg, len + 1, fmt, ap) : -1;
> > + }
> > +
> > /* len does not include the final \0 */
> > if (len < 0)
> > goto end;
> > __tracepoint_cb_lttng_ust_tracef___event(msg, len,
> > LTTNG_UST_CALLER_IP());
> > - free(msg);
> > end:
> > + if (msg != local_buf)
> > + free(msg);
> > va_end(ap);
> > }
> > diff --git a/liblttng-ust/tracelog.c b/liblttng-ust/tracelog.c
> > index 65fc87ed..a5d110fa 100644
> > --- a/liblttng-ust/tracelog.c
> > +++ b/liblttng-ust/tracelog.c
> > @@ -35,19 +35,25 @@
> > const char *fmt, ...) \
> > { \
> > va_list ap; \
> > - char *msg; \
> > + char local_buf[512]; \
> > + char *msg = local_buf; \
> > int len; \
> > \
> > va_start(ap, fmt); \
> > - len = vasprintf(, fmt, ap); \
> > + len = vsnprintf(local_buf, sizeof(local_buf), fmt, ap); \
> > + if (len >= sizeof(local_buf)) { \
> > + msg = (char *)malloc(len + 1); \
> > + len = msg ? vsnprintf(msg, len + 1, fmt, ap) : -1; \
> > + } \
> > /* len does not include the final \0 */ \
> > if (len < 0) \
> > goto end; \
> > __tracepoint_cb_lttng_ust_tracelog___##level(file, \
> > line, func, msg, len, \
> > LTTNG_UST_CALLER_IP()); \
> > - free(msg); \
> > end: \
> > + if (msg != local_buf) \
> > + free(msg); \
> > va_end(ap); \
> > }
> >
> > --
> > 2.30.2
> >
> > ___
> > lttng-dev mailing list
> > lttng-dev@lists.lttng.org
> > https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
This patch was intended for 2.12, no src/common/tracer.h there.
Also this patch is brocken, as a va_list cant be iterated twice.
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] [PATCH lttng-ust] Improve tracef/tracelog to use the stack for small strings
Support two common cases, one being that the resulting message is
small enough to fit into a on-stack buffer.
The seconds being the common 'printf("%s", "Message")' scheme.
Unfortunately, iterating a va_list is destructive,
so it has to be copied before calling vprintf.
This will result in the function never becoming inlined,
thus the helper function was manually "inlined".
Signed-off-by: Norbert Lange
---
src/common/tracer.h | 2 +
src/lib/lttng-ust/tracef.c | 83 -
src/lib/lttng-ust/tracelog.c | 90
3 files changed, 122 insertions(+), 53 deletions(-)
diff --git a/src/common/tracer.h b/src/common/tracer.h
index 2affd6ab..8e18c9b5 100644
--- a/src/common/tracer.h
+++ b/src/common/tracer.h
@@ -26,6 +26,8 @@
#define LTTNG_RFLAG_EXTENDED RING_BUFFER_RFLAG_END
#define LTTNG_RFLAG_END(LTTNG_RFLAG_EXTENDED << 1)
+#define LTTNG_TRACE_PRINTF_BUFSIZE 512
+
/*
* LTTng client type enumeration. Used by the consumer to map the
* callbacks from its own address space.
diff --git a/src/lib/lttng-ust/tracef.c b/src/lib/lttng-ust/tracef.c
index c05c7811..21af5b9e 100644
--- a/src/lib/lttng-ust/tracef.c
+++ b/src/lib/lttng-ust/tracef.c
@@ -7,6 +7,7 @@
#define _LGPL_SOURCE
#include
#include "common/macros.h"
+#include "common/tracer.h"
/* The tracepoint definition is public, but the provider definition is hidden.
*/
#define LTTNG_UST_TRACEPOINT_PROVIDER_HIDDEN_DEFINITION
@@ -15,30 +16,40 @@
#define LTTNG_UST_TRACEPOINT_DEFINE
#include "lttng-ust-tracef-provider.h"
-static inline
-void lttng_ust___vtracef(const char *fmt, va_list ap)
- __attribute__((always_inline, format(printf, 1, 0)));
-static inline
-void lttng_ust___vtracef(const char *fmt, va_list ap)
-{
- char *msg;
- const int len = vasprintf(, fmt, ap);
-
- /* len does not include the final \0 */
- if (len < 0)
- goto end;
- lttng_ust_tracepoint_cb_lttng_ust_tracef___event(msg, len,
- LTTNG_UST_CALLER_IP());
- free(msg);
-end:
- return;
-}
-
void lttng_ust__vtracef(const char *fmt, va_list ap)
__attribute__((format(printf, 1, 0)));
void lttng_ust__vtracef(const char *fmt, va_list ap)
{
- lttng_ust___vtracef(fmt, ap);
+ char local_buf[LTTNG_TRACE_PRINTF_BUFSIZE];
+ char *alloc_buff = NULL;
+ char *msg = local_buf;
+ size_t buflen = sizeof(local_buf);
+ int len = -1;
+
+ if (caa_unlikely(fmt[0] == '%' && fmt[1] == 's' && fmt[2] == '\0')) {
+ msg = va_arg(ap, char *);
+ len = strlen(msg);
+ } else
+ do {
+ va_list ap2;
+
+ if (caa_unlikely(len >= sizeof(local_buf))) {
+ buflen = (size_t)(len) + 1U;
+ alloc_buff = (char *)malloc(buflen);
+ msg = alloc_buff;
+ if (!alloc_buff)
+ return;
+ }
+ va_copy(ap2, ap);
+ len = vsnprintf(msg, buflen, fmt, ap2);
+ va_end(ap2);
+ } while (caa_unlikely(len >= sizeof(local_buf) && !alloc_buff));
+
+ /* len does not include the final \0 */
+ if (caa_likely(len >= 0))
+ lttng_ust_tracepoint_cb_lttng_ust_tracef___event(msg, len,
+ LTTNG_UST_CALLER_IP());
+ free(alloc_buff);
}
void lttng_ust__tracef(const char *fmt, ...)
@@ -46,8 +57,34 @@ void lttng_ust__tracef(const char *fmt, ...)
void lttng_ust__tracef(const char *fmt, ...)
{
va_list ap;
+ char local_buf[LTTNG_TRACE_PRINTF_BUFSIZE];
+ char *alloc_buff = NULL;
+ char *msg = local_buf;
+ size_t buflen = sizeof(local_buf);
+ int len = -1;
- va_start(ap, fmt);
- lttng_ust___vtracef(fmt, ap);
- va_end(ap);
+ if (caa_unlikely(fmt[0] == '%' && fmt[1] == 's' && fmt[2] == '\0')) {
+ va_start(ap, fmt);
+ msg = va_arg(ap, char *);
+ va_end(ap);
+ len = strlen(msg);
+ } else
+ do {
+ if (caa_unlikely(len >= sizeof(local_buf))) {
+ buflen = (size_t)(len) + 1U;
+ alloc_buff = (char *)malloc(buflen);
+ msg = alloc_buff;
+ if (!alloc_buff)
+ return;
+ }
+ va_start(ap, fmt);
+ len = vsnprintf(msg, buflen, fmt, ap);
+ va_end(ap);
+ } while (caa_unlikely(len >= sizeof(local_buf) && !alloc_buff));
+
+ /* len does not include the final \0 */
+ if (caa_likely(len >= 0))
+
[lttng-dev] [PATCH lttng-ust] Improve tracelog handling, reduce exported functions
Instead of creating functions for each loglevel, simply pass the
callback as argument.
Further pack all preprocessor information into a struct that
the compiler already can prepare.
Signed-off-by: Norbert Lange
---
include/lttng/tracelog.h | 49 +
src/lib/lttng-ust/tracelog.c | 130 +++
2 files changed, 75 insertions(+), 104 deletions(-)
diff --git a/include/lttng/tracelog.h b/include/lttng/tracelog.h
index e97c8275..cd5032e3 100644
--- a/include/lttng/tracelog.h
+++ b/include/lttng/tracelog.h
@@ -14,51 +14,40 @@
extern "C" {
#endif
-#define LTTNG_UST_TP_TRACELOG_CB_TEMPLATE(level)
\
- extern void lttng_ust__tracelog_##level(const char *file, \
- int line, const char *func, const char *fmt, ...) \
- __attribute__ ((format(printf, 4, 5))); \
- \
- extern void lttng_ust__vtracelog_##level(const char *file, \
- int line, const char *func, const char *fmt,\
- va_list ap) \
- __attribute__ ((format(printf, 4, 0)));
-
-LTTNG_UST_TP_TRACELOG_CB_TEMPLATE(LTTNG_UST_TRACEPOINT_LOGLEVEL_EMERG);
-LTTNG_UST_TP_TRACELOG_CB_TEMPLATE(LTTNG_UST_TRACEPOINT_LOGLEVEL_ALERT);
-LTTNG_UST_TP_TRACELOG_CB_TEMPLATE(LTTNG_UST_TRACEPOINT_LOGLEVEL_CRIT);
-LTTNG_UST_TP_TRACELOG_CB_TEMPLATE(LTTNG_UST_TRACEPOINT_LOGLEVEL_ERR);
-LTTNG_UST_TP_TRACELOG_CB_TEMPLATE(LTTNG_UST_TRACEPOINT_LOGLEVEL_WARNING);
-LTTNG_UST_TP_TRACELOG_CB_TEMPLATE(LTTNG_UST_TRACEPOINT_LOGLEVEL_NOTICE);
-LTTNG_UST_TP_TRACELOG_CB_TEMPLATE(LTTNG_UST_TRACEPOINT_LOGLEVEL_INFO);
-LTTNG_UST_TP_TRACELOG_CB_TEMPLATE(LTTNG_UST_TRACEPOINT_LOGLEVEL_DEBUG_SYSTEM);
-LTTNG_UST_TP_TRACELOG_CB_TEMPLATE(LTTNG_UST_TRACEPOINT_LOGLEVEL_DEBUG_PROGRAM);
-LTTNG_UST_TP_TRACELOG_CB_TEMPLATE(LTTNG_UST_TRACEPOINT_LOGLEVEL_DEBUG_PROCESS);
-LTTNG_UST_TP_TRACELOG_CB_TEMPLATE(LTTNG_UST_TRACEPOINT_LOGLEVEL_DEBUG_MODULE);
-LTTNG_UST_TP_TRACELOG_CB_TEMPLATE(LTTNG_UST_TRACEPOINT_LOGLEVEL_DEBUG_UNIT);
-LTTNG_UST_TP_TRACELOG_CB_TEMPLATE(LTTNG_UST_TRACEPOINT_LOGLEVEL_DEBUG_FUNCTION);
-LTTNG_UST_TP_TRACELOG_CB_TEMPLATE(LTTNG_UST_TRACEPOINT_LOGLEVEL_DEBUG_LINE);
-LTTNG_UST_TP_TRACELOG_CB_TEMPLATE(LTTNG_UST_TRACEPOINT_LOGLEVEL_DEBUG);
-
-#undef LTTNG_UST_TP_TRACELOG_CB_TEMPLATE
+struct lttng_ust__tracelog_sourceinfo {
+ const char *file;
+ const char *func;
+ int line;
+};
+
+extern void lttng_ust__tracelog_printf(
+
__typeof__(lttng_ust_tracepoint_cb_lttng_ust_tracelog___LTTNG_UST_TRACEPOINT_LOGLEVEL_DEBUG)
*callback,
+ const struct lttng_ust__tracelog_sourceinfo *source, const char *fmt,
...)
+ __attribute__ ((format(printf, 3, 4)));
+
+extern void lttng_ust__tracelog_vprintf(
+
__typeof__(lttng_ust_tracepoint_cb_lttng_ust_tracelog___LTTNG_UST_TRACEPOINT_LOGLEVEL_DEBUG)
*callback,
+ const struct lttng_ust__tracelog_sourceinfo *source, const char *fmt,
va_list ap)
+ __attribute__ ((format(printf, 3, 0)));
#define lttng_ust_tracelog(level, fmt, ...)
\
do {\
+ static const struct lttng_ust__tracelog_sourceinfo src = {
__FILE__, __func__, __LINE__ }; \
LTTNG_UST_STAP_PROBEV(tracepoint_lttng_ust_tracelog, level, ##
__VA_ARGS__); \
if
(caa_unlikely(lttng_ust_tracepoint_lttng_ust_tracelog___##level.state)) \
- lttng_ust__tracelog_##level(__FILE__, __LINE__,
__func__, \
+
lttng_ust__tracelog_printf(_ust_tracepoint_cb_lttng_ust_tracelog___##level,
, \
fmt, ## __VA_ARGS__); \
} while (0)
#define lttng_ust_vtracelog(level, fmt, ap)
\
do {\
+ static const struct lttng_ust__tracelog_sourceinfo src = {
__FILE__, __func__, __LINE__ }; \
if
(caa_unlikely(lttng_ust_tracepoint_lttng_ust_tracelog___##level.state)) \
- lttng_ust__vtracelog_##level(__FILE__, __LINE__,
__func__, \
+
lttng_ust__tracelog_vprintf(_ust_tracepoint_cb_lttng_ust_tracelog___##level,
, \
fmt, ap); \
} while (0)
#if LTTNG_UST_COMPAT_API(0)
-#define TP_TRACELOG_CB_TEMPLATE LTTNG_UST_TP_TRACELOG_CB_TEMPLATE
#define tracelog lttng_ust_tracelog
#define vtracelog lttng_ust_vtracelog
#endif
diff --git a/src/lib/lttng-ust/tracelog.c b/src/lib/lttng-ust/tracelog.c
index 8147d7a3..b28c6c78 100644
--- a/src/lib/lttng-ust/tracelog.c
+++ b/src/lib/lttng-ust/tracelog.c
@@ -15,78 +15,60 @@
#define LTTNG_UST_TRACEPOINT_DEFINE
#include
Re: [lttng-dev] LTTng - Xenomai : different results between timestamp-lttng and rt_time_read()
Am Do., 20. Mai 2021 um 10:28 Uhr schrieb MONTET Julien : > > Hi Norbert, > > Thank you for your answer ! > > Yes, I am using a Xenomai cobalt - xenomai is 3.1 > cat /proc/xenomai/version => 3.1 > > After the installation, I tested "test tools" in /proc/xenomai/ and it worked > nice. Just asked to make sure, thought the scripts usual add some -xeno tag to the kernel version. > What do you mean by "it might deadlock really good" ? clock_gettime will either use a syscall (kills realtime always) or is optimized via VDSO (which very likely is your case). What happens is that the kernel will take a spinlock, then write new values, then releases the spinlock. your program will aswell spin (but just to see if the spinlock is free), read the values and interpolates them. But if your program interrupts the kernel while the kernel holds the lock (all on the same cpu core), then it will spin forever and the kernel will never execute. The ugly truth is, that any library you use could call those functions, you need to very closely look at your realtime path. Some checkers can help: https://github.com/nolange/preload_checkers Norbert. ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
Re: [lttng-dev] LTTng - Xenomai : different results between timestamp-lttng and rt_time_read()
Am Do., 20. Mai 2021 um 09:58 Uhr schrieb MONTET Julien via lttng-dev
:
>
> Hi the developers !
>
> CONTEXT
> I am currently working on a Raspberry pi 3B with Xenomai and LTTng tools.
> Raspbian 10.9 Buster - kernel 4.19.85
> uname -a : Linux raspberrypi 4.19.85-v7+ #5 SMP PREEMPT Wed May 12 10:13:37
> Both tools are working, but I wonder about the accuracy of LTTng libraries.
>
>
> METHOD
> The code used is quite simple, it is written with the alchemy skin.
> A rt_task_spawn calls a function that has rt_task_set_periodic(NULL, TM_NOW,
> period) and rt_task_wait_period(NULL).
> ->The rt_task_set_periodic is based on 1ms.
> ->The rt_task_wait_period(NULL) is of course inside a while loop (see below
> at the very end).
>
> My goal is to get accurate traces from Xenomai.
> I took two methods to do so :
> -> lttng
> -> basic calculation based on rt_timer_read()
>
> What a surprise when I found both method have two different results.
> -> LTTng shows me traces [0.870;1.13] ms (or even less precise)
> -> rt_time_read shows me traces [0.980;1.020] ms
>
> Thing to note :
> -> The use of LTTng has no influence on rt_time_read(), you can use both
> methods at the same time.
>
> Then, I saved the output of rt_time_read inside a tracepoint.
> It appeared the LTTng is always called at the right time because the value
> got by rt_time_read () is really good.
>
>
> QUESTIONS
> These are now my questions :
> - What is the method I should trust ?
> - I have searched on the forum and I found LTTng uses a MONOTONIC clock for
> the timestamp. Can/Should I modify it ?
>
>
> CODE
> ---
> A small part of my function called by rt_task_spawn :
> [...]
> RTIME period = 1000*1000; // in ns
> RTIME now;
> RTIME previous = 0;
> RTIME duration;
> [...]
> while(1)
> {
> overruns = 0;
> err = rt_task_wait_period();
> now = rt_timer_read();
> tracepoint(tp_provider, tracepoint_tick_ms, now, "tick");
>
> if (previous != 0)
> {
> duration=now-previous;
> rt_printf("%llu\n \n", duration/1000);
> }
>previous=now;
>[...]
> }
Are you using the Xenomai kernel ("Cobalt"), or just skins via
copperplate ("Mercury")?
You have some file /proc/xenomai/version?
The Xenomai kernel has his own clock, which in general is not
correlated to the linux monotonic clock.
(Under some circumstances it might be identical).
My plan is to use a clock plugin for Lttng, particularly because if
lttng uses the linux monotonic clock from a realtime thread
it might deadlock really good ;)
Norbert
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] [PATCH] Avoid using the heap for small strings with tracef/tracelog
Try to use vsnprintf with a 512 Byte buffer on the Stack,
if that fails allocate a larger one.
Signed-off-by: Norbert Lange
---
liblttng-ust/tracef.c | 13 ++---
liblttng-ust/tracelog.c | 12 +---
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/liblttng-ust/tracef.c b/liblttng-ust/tracef.c
index ea98e43e..18c29e25 100644
--- a/liblttng-ust/tracef.c
+++ b/liblttng-ust/tracef.c
@@ -32,17 +32,24 @@
void _lttng_ust_tracef(const char *fmt, ...)
{
va_list ap;
- char *msg;
+ char local_buf[512];
+ char *msg = local_buf;
int len;
va_start(ap, fmt);
- len = vasprintf(, fmt, ap);
+ len = vsnprintf(local_buf, sizeof(local_buf), fmt, ap);
+ if (len >= sizeof(local_buf)) {
+ msg = (char *)malloc(len + 1);
+ len = msg ? vsnprintf(msg, len + 1, fmt, ap) : -1;
+ }
+
/* len does not include the final \0 */
if (len < 0)
goto end;
__tracepoint_cb_lttng_ust_tracef___event(msg, len,
LTTNG_UST_CALLER_IP());
- free(msg);
end:
+ if (msg != local_buf)
+ free(msg);
va_end(ap);
}
diff --git a/liblttng-ust/tracelog.c b/liblttng-ust/tracelog.c
index 65fc87ed..a5d110fa 100644
--- a/liblttng-ust/tracelog.c
+++ b/liblttng-ust/tracelog.c
@@ -35,19 +35,25 @@
const char *fmt, ...) \
{ \
va_list ap; \
- char *msg; \
+ char local_buf[512]; \
+ char *msg = local_buf; \
int len; \
\
va_start(ap, fmt); \
- len = vasprintf(, fmt, ap); \
+ len = vsnprintf(local_buf, sizeof(local_buf), fmt, ap); \
+ if (len >= sizeof(local_buf)) { \
+ msg = (char *)malloc(len + 1); \
+ len = msg ? vsnprintf(msg, len + 1, fmt, ap) : -1; \
+ } \
/* len does not include the final \0 */ \
if (len < 0) \
goto end; \
__tracepoint_cb_lttng_ust_tracelog___##level(file, \
line, func, msg, len, \
LTTNG_UST_CALLER_IP()); \
- free(msg); \
end: \
+ if (msg != local_buf) \
+ free(msg); \
va_end(ap); \
}
--
2.30.2
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] reading context fields causes syscalls
Hello, Several context fields will cause a syscall atleast the first time a tracepoint is recorded. For example all of the following: `lttng add-context -c chan --userspace --type=vpid --type=vtid --type=procname` Each of them seems cached in TLS however, and most should never change after startup. As I am using Lttng over Xenomai, syscalls are strictly forbidden, I would like to have some function that prepares all data, which I can call on each thread before it switches to realtime work. Kinda similar to urcu_bp_register_thread, I'd like to have some `lttng_ust_warmup_thread` function that fetches the context values that can be cached. (urcu_bp_register_thread should be called there aswell) I considered just doing a tracepoint, but AFAIK the channel can be changed/configured after the process is running. So this is not robust enough. regards, Norbert ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
[lttng-dev] tracelog / tracef feature
Hello, I finally got some time digging into Lttng (using it on Xenomai, see [1] for historic reference). Since we have a hard realtime system, I chosen to use dynamic probes. That means only liblttng-ust-tracepoint.so wil get pulled into the process (it its available), no threads are spawned, etc. This is to minimize potential issues, without dealing with compiletime selection/macros. (Pre-)loading the tracepoint library will then pull in liblttng-ust.so. So far so good, but I found out that tracepoint/tracef are unusable currently. First you need to link with liblttng-ust.so, then you have vasprintf doing memory allocations. I did a custom solution with dynamic loading. # Outlined custom solution The own binary gets a sourcefile similar to ```c #define TRACEPOINT_DEFINE #define TRACEPOINT_PROBE_DYNAMIC_LINKAGE #include ``` There is no need to add the definition to the own tracepoint library, the binaries tracepoint library will depend on `liblttng-ust.so` and the definitions are pulled in if the tracepoint library is loaded. There are a own namespaces variant of macros and wrapper functions ## Issues Thats a short recap, easier to quote and address whether some upstream solution is possible ### Use tracelog / tracef with dynamic probes is there an easy solution for doing this? is the solution of creating the stubs yourself valid? ### Allocations in the tracelog / tracef functions Would you accept a change, where first some buffer on the stack and vsnprintf is used, only in case the buffer is to small a dynamic one will be allocated? ### No Include guards in lttng/lttng-ust-tracelog.h and lttng/lttng-ust-tracef.h Some other issue is that `` does not have include guards and including both the custom implementation and `` will lead to duplicate definitions and compile errors. Regards, Norbert [1] - https://lists.lttng.org/pipermail/lttng-dev/2019-November/029410.html ___ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
