LTTng-UST, the Linux Trace Toolkit Next Generation Userspace Tracer,
is a low-overhead application tracer. The library "liblttng-ust" enables
tracing of applications and libraries.
Version 2.11.2 is a very small bugfix release which includes only a
single fix affecting the LTTng filter
The LTTng modules provide Linux kernel tracing capability to the LTTng
tracer toolset.
This announcement covers the 2.10.15 and 2.11.3 stable branch releases
for the LTTng-modules project. The 2.10.15 version will be the last for
the 2.10 branch given that the 2.12 final release is expected
Hi,
This announcement introduces the 0.12 version of liburcu.
liburcu is a LGPLv2.1 userspace RCU (read-copy-update) library. This
data synchronization library provides read-side access which scales
linearly with the number of cores. It does so by allowing multiple
copies of a given data
- On Apr 20, 2020, at 4:17 PM, lttng-dev lttng-dev@lists.lttng.org wrote:
> Hi all,
>
> When creating live session (lttng create --live) I can not enable rotation:
>
> # lttng enable-rotation --size=10M
> Error: Failed to enable size-based rotation schedule on session BX
This is indeed the
Hi Florian,
Sorry, I could not apply this patch due to line-wrapping performed
by your email client. Please use git send-email.
Thanks,
Mathieu
- On Mar 13, 2020, at 7:32 AM, lttng-dev lttng-dev@lists.lttng.org wrote:
> * UDP transport header
> * ICMP transport header
>
> (Correct
- On Mar 26, 2020, at 1:39 PM, lttng-dev wrote:
> Hello!
> Currently, callstack collection in LTTng is only available for kernel-space
> events with context fields callstack-kernel and callstack-user .
> Is it expected that callstack collection for LTTng-UST will be added too? And
> if
>
Hi,
This release announcement of LTTng-modules 2.12.0-rc3 and LTTng-UST 2.12.0-rc3
comes at an interesting time, where the entire EfficiOS team bringing you this
release is working from home, following the physical distancing guidelines from
Quebec's government.
Those are likely the very last
< [
> mailto:milian.wo...@kdab.com |
> milian.wo...@kdab.com ] > wrote:
>> On Donnerstag, 26. März 2020 20:41:17 CET Mathieu Desnoyers via lttng-dev
>> wrote:
>>> - On Mar 26, 2020, at 1:39 PM, lttng-dev < [
>> > mailto:lttng-dev@lists.lttng.org | lt
Signed-off-by: Mathieu Desnoyers
---
common-trace-format-specification.md | 3 +++
1 file changed, 3 insertions(+)
diff --git a/common-trace-format-specification.md
b/common-trace-format-specification.md
index fd49e59..d6d196c 100644
--- a/common-trace-format-specification.md
+++
Signed-off-by: Mathieu Desnoyers
---
common-trace-format-specification.md | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/common-trace-format-specification.md
b/common-trace-format-specification.md
index 55d0601..5732e92 100644
---
Signed-off-by: Mathieu Desnoyers
---
common-trace-format-specification.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/common-trace-format-specification.md
b/common-trace-format-specification.md
index 5732e92..8a3a745 100644
---
Signed-off-by: Mathieu Desnoyers
---
common-trace-format-specification.md | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/common-trace-format-specification.md
b/common-trace-format-specification.md
index d6d196c..55d0601 100644
---
- On Apr 28, 2020, at 2:40 PM, Philippe Proulx ppro...@efficios.com wrote:
> - Original Message -
>> From: "Mathieu Desnoyers"
>> To: "gbastien+lttng" , "Matthew Khouzam"
>> ,
>> diamon-disc...@linuxfoundation.org, ppro...@efficios.com, "Jeremie Galarneau"
>>
>> Cc: "lttng-dev" ,
- On Apr 28, 2020, at 2:42 PM, Philippe Proulx ppro...@efficios.com wrote:
> - Original Message -
>> From: "Mathieu Desnoyers"
>> To: "gbastien+lttng" , "Matthew Khouzam"
>> ,
>> diamon-disc...@linuxfoundation.org, ppro...@efficios.com, "Jeremie Galarneau"
>>
>> Cc: "lttng-dev" ,
- On Apr 23, 2020, at 6:51 PM, Jeremie Galarneau
jeremie.galarn...@efficios.com wrote:
> On Thu, 23 Apr 2020 at 16:52, Mathieu Desnoyers
> wrote:
>>
>> From: Geneviève Bastien
>>
>> Signed-off-by: Geneviève Bastien
>> Signed-off-by: Mathieu Desnoyers
>> ---
>>
- On Apr 21, 2020, at 5:37 PM, Sergei Dyshel qyron.priv...@gmail.com wrote:
[...]
>
>> Considering that there are few compelling use-cases for using both
>> features together, and no customer have expressed interest in this,
>> it is not part of our roadmap.
>
> Here is my case: I'm using
Hi,
This is a release announcement for the liburcu project. Those releases
are bugfix only releases within each of the currently supported
branches: 0.12.1, 0.11.2, 0.10.3, 0.9.7.
Note that the 0.9.7 and 0.10.3 releases mark the end of life of the
stable-0.9 and stable-0.10 branches. Users
- On Apr 28, 2020, at 2:51 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Apr 28, 2020, at 2:40 PM, Philippe Proulx ppro...@efficios.com wrote:
>
>> - Original Message -
>>> From: "Mathieu Desnoyers"
>>> To: "gbastien+lttng" , "Matthew Khouzam"
>>> ,
>>>
Signed-off-by: Mathieu Desnoyers
---
common-trace-format-specification.md | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/common-trace-format-specification.md
b/common-trace-format-specification.md
index 53b70f4..7681ce5 100644
---
From: Geneviève Bastien
Signed-off-by: Geneviève Bastien
Signed-off-by: Mathieu Desnoyers
---
common-trace-format-specification.md | 3 +++
1 file changed, 3 insertions(+)
diff --git a/common-trace-format-specification.md
b/common-trace-format-specification.md
index fd49e59..f5fea51 100644
Signed-off-by: Mathieu Desnoyers
---
common-trace-format-specification.md | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/common-trace-format-specification.md
b/common-trace-format-specification.md
index f5fea51..53b70f4 100644
---
Hi,
We noticed a few unspecified areas in the CTF 1.8.2 specification which
require some clarifications. We therefore plan to do a 1.8.3 release of
the specification including those changes.
Review is welcome,
Thanks,
Mathieu
Geneviève Bastien (1):
Clarify that unlisted enum values are
- On Apr 22, 2020, at 2:18 PM, Sergei Dyshel qyron.priv...@gmail.com wrote:
> Thanks! I really missed this feature somehow.
>
> However I see that passing 0 as "tracefile size" will remove size
> limitation. Is it possible to disable CTF trace writing altogether?
No, because the relay
- On May 11, 2020, at 5:09 PM, lttng-dev wrote:
> Hi,
> As part of a big software safety certification effort, we are looking into
> making sure that some functions of our API do not allocate memory and do not
> use any blocking syscalls.
> This part is done and is working (using
Linux commit 0bd476e6c67190b5eb7b6e105c8db8ff61103281 ("kallsyms:
unexport kallsyms_lookup_name() and kallsyms_on_each_symbol()") breaks
LTTng-modules by removing symbols used by the LTTng-modules out-of-tree
tracer.
I pointed this out when the change was originally considered before the
5.7
- On May 15, 2020, at 1:16 PM, lttng-dev wrote:
> I am tracing a multiprocess/multithreaded code (MPI/OpenMP) using lttng-ust.
> Right now, I need to include process id and thread id for each event in order
> to generate process/thread indexed view of the traces. Is there a way that I
> can
Merged into lttng-modules master branch, thanks!
Mathieu
- On Mar 17, 2020, at 5:03 AM, lttng-dev lttng-dev@lists.lttng.org wrote:
> * UDP transport header
> * ICMP transport header
>
> (Correct indentation for switch/case)
> (Fix whitespace for switch and correct struct type (icmphdr))
>
- On Sep 2, 2020, at 10:53 PM, 熊毓华 wrote:
> Thanks，now I understand the tracking policy of lttng.
> And I want to know，do you have any plans for "exclusion set"?
Not at this point. None of our customers expressed interest in that feature so
far.
Thanks,
Mathieu
--
Mathieu Desnoyers
Hi,
These releases include a security fix for the LTTng kernel tracer.
This issue was introduced very early in the LTTng modules 2.0 development,
prior to the lttng-modules v2.0.0 release. Therefore all lttng-modules
releases are affected. Users are encouraged to upgrade.
See master branch
- On Oct 12, 2020, at 5:04 AM, lttng-dev lttng-dev@lists.lttng.org wrote:
> Hi all,
>
> I have recently started using LTTng and stumbled upon the fact, that
> LTTng is keeping a lot of open file pointers to a single deleted file.
>
> Specifically the process that holds these open is the
- On Oct 20, 2020, at 2:59 AM, lttng-dev wrote:
> Hi All,
> I’m facing compilation error in build after pulling in the stable kernel
> LTS(4.14.y) commit - [
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.14.y=77322edb99f0176ec67a300b9f263719ba391b89
>
- On Sep 27, 2020, at 9:54 AM, lttng-dev lttng-dev@lists.lttng.org wrote:
> Hello!
> Is it planned to publish LTTng 2.12 packages for Linux distributives except
> Ubuntu and Debian. Packages for RedHat / CentOS, Fedora, Arch, etc are
> available for previous versions.
Hi,
Packaging is a
- On May 28, 2020, at 7:51 AM, lttng-dev lttng-dev@lists.lttng.org wrote:
> Hello,
>
> First - of all: thank you very much for efforts to develop and
> maintain LTTng. It's very useful tool!
> I used it so far on PowerPC targets and now I try to run it on ARM:
> Cyclone5 ARMv7 CPU.
>
> When
Introduce --with-babeltrace-test-bin to allow specifying which
babeltrace binary should be used in tests.
If this option is not specified, use the babeltrace2 binary if found,
else fall back on babeltrace.
When looking for babeltrace2 and babeltrace, abide by
--with-babeltrace2-bin and
- On Sep 16, 2020, at 3:57 AM, lttng-dev wrote:
> Hello All,
> I'm trying to configure Lttng-UST and disabling shared libraries using the
> option --enable-shared=no.
> I always get an Error that Lttng-UST requires shared libraries enabled.
> Why is this option available if I can't use it
- On Oct 22, 2020, at 6:30 PM, paulmck paul...@kernel.org wrote:
> The current code can lose RCU callbacks at shutdown time, which can
> result in hangs. This lossage can happen as follows:
>
> o A thread invokes call_rcu_data_free(), which executes up through
>the
- On Jul 15, 2020, at 2:28 PM, rostedt rost...@goodmis.org wrote:
> On Wed, 15 Jul 2020 20:37:16 +0430
> ahmadkhorrami wrote:
>
>> Hi,
>> What is the most efficient way to capture occurrence of a function
>> call/return of a binary program in userspace?
>> It seems the answer is Uprobes. 1)
- On Aug 7, 2020, at 3:24 AM, lttng-dev wrote:
> Hi,
> I am new for using rcu and I need some helps for integrating user space rcu
> into
> my project for solving performance issue.
> In my project, I create 2 link list - one for free pool, one for using pool.
> Free pool used to hold a
Hi,
The releases 2.11.5 and 2.12.2 of LTTng-modules are bug fix releases, which
also add support for the recently released Linux kernel 5.8.
The LTTng modules provide Linux kernel tracing capability to the LTTng
tracer toolset.
Project website: https://lttng.org
Documentation:
Hi,
Make sure you use single quotes in your shell around wildcards, else the
shell will try to expand them to files in the current directory, e.g., you need
to do:
lttng enable-event -u 'system_event*' -c channel0 -s misc_data
This could very well explain why sometimes your events don't
- On Jul 2, 2020, at 8:45 AM, Jonathan Rajotte
jonathan.rajotte-jul...@efficios.com wrote:
> On Thu, Jul 02, 2020 at 08:38:57AM +0800, zhenyu.ren via lttng-dev wrote:
>> Thanks a lot. I will try single quotes but it may take hours get the result.
>> Yesterday, I enabled the verbose option
- On Jul 9, 2020, at 7:19 AM, lttng-dev wrote:
> Hello!
> Currently, I'm developing a process monitor on the base of LTTng, and I face
> the
> challenge of accessing command-line arguments passed to execve syscall.
> I'm using LTTng live session and Babeltrace 2 C API to analyze events in
- On Jul 13, 2020, at 11:19 AM, Olivier Dion olivier.d...@polymtl.ca wrote:
> On Mon, 13 Jul 2020, Mathieu Desnoyers wrote:
[...]
>
Also, we should compare two approaches to fulfill your goal:
one alternative would be to have application/library constructors
explicitly call
- On Jul 12, 2020, at 11:49 AM, Olivier Dion olivier.d...@polymtl.ca wrote:
> On Sun, 12 Jul 2020, Mathieu Desnoyers wrote:
>> - On Jul 11, 2020, at 11:29 AM, lttng-dev lttng-dev@lists.lttng.org
>> wrote:
>>
>>> Some library might want to generate events in their ctor/dtor. If
>>>
- On Jul 13, 2020, at 2:46 PM, Olivier Dion olivier.d...@polymtl.ca wrote:
> On Mon, 13 Jul 2020, Mathieu Desnoyers wrote:
>> - On Jul 13, 2020, at 11:19 AM, Olivier Dion olivier.d...@polymtl.ca
>> wrote:
>>
>>> On Mon, 13 Jul 2020, Mathieu Desnoyers
>>> wrote:
>> [...]
>>>
>>
- On Jul 13, 2020, at 10:56 PM, lttng-dev lttng-dev@lists.lttng.org wrote:
> Hi all,
>
> Does anybody know if there is a custom field support in lttng-ust (to
> export atype_struct and atype_variant data fields) like in
> lttng-modules (ctf_custom_field)?
No, there is not.
Thanks,
Mathieu
- On Jul 11, 2020, at 11:29 AM, lttng-dev lttng-dev@lists.lttng.org wrote:
> Some library might want to generate events in their ctor/dtor. If
> LTTng initialize/finalize its tracepoints/events at the wrong time,
> events are lost.
>
> Order of execution of the ctor/dtor is determined by
Hi,
This is an announcement of a patch level 1.8.3 update for the Common
Trace Format. It clarifies a few unspecified areas of CTF 1.8.2.
You can find the specification at:
https://diamon.org/ctf/
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
Hi,
This is a release announcement of the LTTng kernel tracer for both
maintained LTTng stable branches. The main change integrated within
the new versions 2.12.1 and 2.11.4 is support for the newly released
5.7 Linux kernel.
If you followed the news lately [1], you will notice that LTTng had to
- On Jun 3, 2020, at 8:36 AM, lttng-dev lttng-dev@lists.lttng.org wrote:
> I've compiled userspace-rcu with:
>
> CC=gcc CFLAGS='-O0 -g3 -fsanitize=undefined' LIBS='-lubsan' ./configure [xxx]
>
> and see a lot of 'misaligned address' runtime errors like:
>
> ./doc/examples/urcu-flavors/bp
Clarify that both offset_s and offset fields of clock may have
negative values.
Signed-off-by: Mathieu Desnoyers
---
common-trace-format-specification.md | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/common-trace-format-specification.md
Hi,
I just released versions 2.11.7 and 2.12.4 of the lttng-modules stable branches.
These add support for the 5.10 Linux kernel.
Please try them out, and, as usual, feedback is welcome!
Thanks,
Mathieu
Project website: https://lttng.org
Documentation: https://lttng.org/docs
Download link:
- On Nov 28, 2020, at 1:49 AM, 熊毓华 xiongyu...@zju.edu.cn wrote:
> Hi,
> I put my test scripts in the attachment.
> You can just run the script directly, create the trace session with the
> "--live"
> option on the 8core server,
> then you will find the cpu usage of the lttng-consumerd
- On Nov 27, 2020, at 11:04 AM, lttng-dev lttng-dev@lists.lttng.org wrote:
> Well we also want to know why! You will understand that albeit we develop
> lttng
> we do not always have a quick and easy answer to all problems. Performance
> related problem are always tricky.
> And we also have
Hi Paul,
Should I merge this temporary fix for liburcu tests, or should we go
for dynamic allocation of the array right away instead ?
Thanks,
Mathieu
- On Dec 9, 2020, at 1:15 PM, Michael Jeanson mjean...@efficios.com wrote:
> Machines with more than 128 CPUs are becomming more common,
Merged in liburcu master, thanks!
Mathieu
- On Dec 15, 2020, at 11:28 AM, Michael Jeanson mjean...@efficios.com wrote:
> Remove the configure time CONFIG_RCU_ARM_HAVE_DMB option and replace it
> by compile time detection based on the ARM ISA version. This makes sure
> we unconditionnaly use
Merged in liburcu master, thanks!
Mathieu
- On Dec 15, 2020, at 11:28 AM, Michael Jeanson mjean...@efficios.com wrote:
> GCC added __sync_synchronize() in 4.4.0 but it was broken on ARM until
> 4.4.3, see the GCC bug report for more details :
>
>
Merged in liburcu master, thanks!
Mathieu
- On Dec 15, 2020, at 11:28 AM, Michael Jeanson mjean...@efficios.com wrote:
> Change-Id: I3e17308c5ae985789a2ac8361e9c9e958ff7d656
> Signed-off-by: Michael Jeanson
> ---
> include/urcu/arch/arm.h | 13 +
> include/urcu/compiler.h | 13
Merged in liburcu master, thanks!
Mathieu
- On Dec 15, 2020, at 11:28 AM, Michael Jeanson mjean...@efficios.com wrote:
> We shouldn't force a specific target cpu for the compiler on ARMv7 but
> let the system or the user choose it. If some of our code depends on a
> specific target CPU
- On Dec 16, 2020, at 4:19 AM, lttng-dev wrote:
> Hi,
> I send this email to consult that whether it is possible to customize lttng
> tracepoints in kernel space. I have learnt that lttng leverages linux
> tracepoint to collect audit logs like system calls. Also, I have found that
> user
Hi Michael,
After discussion with Paul, we can go for bumping the max nr cpu limit
of this test to 4096.
1536 would cover all the current hardware Paul E. McKenney is aware of.
4096 would cover all hardware he has ever received a bug report on.
Can you try it out and submit an updated patch ?
Merged into master, stable-0.11, stable-0.12, thanks!
Mathieu
- On Nov 17, 2020, at 3:22 PM, Michael Jeanson mjean...@efficios.com wrote:
> Signed-off-by: Michael Jeanson
> ---
> include/urcu/debug.h | 2 ++
> include/urcu/uatomic/x86.h | 1 +
> include/urcu/urcu-qsbr.h | 2 ++
>
Merged into master, stable-0.11, stable-0.12, thanks!
Mathieu
- On Nov 17, 2020, at 3:22 PM, Michael Jeanson mjean...@efficios.com wrote:
> Signed-off-by: Michael Jeanson
> ---
> configure.ac | 4 ++--
> include/urcu/config.h.in | 2 +-
> 2 files changed, 3 insertions(+), 3
Hi,
This fix does not apply with "git am", probably due to the fact that the email
is not
formatted as plain text without alteration by your email client. I recommend
using
git send-email to send patches. Can you try sending it again in the proper
format
expected by git am ?
You will
- On Dec 23, 2020, at 9:55 PM, lttng-dev wrote:
> Hi,
> ThI found that lttng is working on container awareness in this slides:
>
- On Jan 17, 2021, at 9:04 PM, lttng-dev lttng-dev@lists.lttng.org wrote:
>
> 发件人: Jonathan Rajotte-Julien
> 发送时间: 2021年1月16日 3:18
> 收件人: Zhang, Qiang
> 抄送: lttng-dev
> 主题: Re: 回复: 回复: help modpost: "__bad_cmpxchg"
>
> [Please note this e-mail is
Hi,
We are currently working on the CTF2 specification [1] at EfficiOS, and there is
a user metric we would need to help us with a design decision with respect
to enumerations. This is where we would need community input.
The usage metrics in question are with respect to LTTng-UST enumeration
Hi Philippe, Hi Jeremie,
Steven is interested to use libbabeltrace as a CTF trace reader in the
KernelShark
project. It's a GUI which shows Linux kernel traces.
He notices that most of the documented usage examples of the libbabeltrace API
focus on use-cases where a custom trace format is
- On Jun 4, 2021, at 9:09 AM, lttng-dev lttng-dev@lists.lttng.org wrote:
> Hi LTTng team,
> I am currently trying to add lttng 32bits on a 64bits system with a custom
> kernel 4.19.177+ x86_64 (Debian 10.9)
> My former attempt only with only a 100% arm32 bits was successful (raspberry).
>
- On Jun 17, 2021, at 6:13 PM, lttng-dev lttng-dev@lists.lttng.org wrote:
> 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
- On May 14, 2021, at 3:52 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> Hi,
>
> The 2.11.9 and 2.12.6 releases of the LTTng kernel tracer are the latest bug
> fix
> releases
> of the 2.11 and 2.12 stable branches of the LTTng modules project.
>
> There are a few minor bug
Hi,
LTTng-UST 2.11.4 and 2.12.2 are bug fix releases of the LTTng-UST user-space
tracer for the
2.11 and 2.12 stable branches.
There are a few fixes, as well as a in-depth rework of the benchmark code which
was sitting
in the tests of lttng-ust. This test code was contributed more than 10
Hi,
The 2.11.9 and 2.12.6 releases of the LTTng kernel tracer are the latest bug
fix releases
of the 2.11 and 2.12 stable branches of the LTTng modules project.
There are a few minor bug fixes, but those are the noteworthy changes:
- Support for 5.12 Linux kernels,
- Support recent stable
- On May 20, 2021, at 1:43 PM, Norbert Lange nolang...@gmail.com wrote:
> 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
- 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
>
- 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,
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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 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
- 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
The error label jumps to the end label which releases the RCU read-side
lock. There are many error paths in this function which goto error
without holding the RCU read-side lock, thus causing unbalanced RCU
read-side lock.
There is no point in keeping so short RCU read-side critical sections,
so
Hi,
The Userspace RCU 0.13 release is mostly a library soname version bump
to address an ABI incompatibility between the 0.10 and { 0.11, 0.12 }
releases.
The observed application vs library compatibility problem occurs as follows:
- An application executable is built with _LGPL_SOURCE defined,
- On Jul 6, 2021, at 10:37 PM, lttng-dev wrote:
> Hi,
> I know lttng-ust tracepoint process uses per cpu lockless ringbuffer algorithm
> for high performance so that it relies on getcpu() to return the cpu number on
> which the app is running.
> Unfortunately, I am working on arm that linux
- On Jul 9, 2021, at 4:30 AM, lttng-dev wrote:
> Hi there, I'm a little new to lttng and tracing in general. I am using a Java
> Userspace agent, which is working well, but I am having trouble adding
> callstack context to my tracing channels. I'm not sure if it's relevant but
> running
- On Apr 29, 2021, at 9:49 AM, lttng-dev lttng-dev@lists.lttng.org wrote:
> In multipath-tools, we are using a custom RCU helper thread, which is cleaned
> out
> on exit:
>
> https://github.com/opensvc/multipath-tools/blob/23a01fa679481ff1144139222fbd2c4c863b78f8/multipathd/main.c#L3058
>
>
Hi everyone,
Today we are releasing the first release candidate of LTTng 2.13 - Nordicité!
This release is the result of 1 year of development from most of the EfficiOS
team.
This release is named after "Nordicité", the product of a collaboration between
Champ Libre and Boréale. This farmhouse
- On May 5, 2021, at 3:54 AM, Martin Wilck mwi...@suse.com wrote:
> On Fri, 2021-04-30 at 14:41 -0400, Mathieu Desnoyers wrote:
>> - On Apr 29, 2021, at 9:49 AM, lttng-dev
>> lttng-dev@lists.lttng.org wrote:
>>
>> > In multipath-tools, we are using a custom RCU helper thread, which
>> >
- On Feb 8, 2021, at 1:04 PM, lttng-dev lttng-dev@lists.lttng.org wrote:
> Dear LTTng developers,
> I was wondering if LTTng currently (or in the future) supports network
> namespaces. For instance, an ambiguity in the logs would make problems for
> future system analysis.
Did you try the
least version enum labels or
> somesuch?
>
> /Jesper
>
> ____________________
> Från: lttng-dev för Mathieu Desnoyers via
> lttng-dev
> Skickat: den 26 januari 2021 16:19
> Till: lttng-dev
> Ämne: [lttng-dev] Community input: Feedback on use of enu
- On Mar 31, 2021, at 2:56 PM, lttng-dev lttng-dev@lists.lttng.org wrote:
> the following tests fails on arm64
> - test_event_vpid_tracker ust 0 "${EVENT_NAME}"
> - test_event_vpid_track_untrack ust 0 "${EVENT_NAME}"
> - test_event_pid_tracker ust 0 "${EVENT_NAME}"
> -
- On Apr 1, 2021, at 12:19 PM, lttng-dev lttng-dev@lists.lttng.org wrote:
> - On Mar 31, 2021, at 2:56 PM, lttng-dev lttng-dev@lists.lttng.org wrote:
>
>> the following tests fails on arm64
>> - test_event_vpid_tracker ust 0 "${EVENT_NAME}"
>> - test_event_vpid_track_untrack ust 0
- On Apr 5, 2021, at 1:43 PM, lttng-dev lttng-dev@lists.lttng.org wrote:
> Hello all,
>
> I am using the QSBR flavor of URCU and I have a question: is it ok to call
> rcu_register_thread more than once per thread?
Yes, but you should unregister before registering again.
> Similarly, is it
- On Apr 1, 2021, at 12:36 PM, lttng-dev lttng-dev@lists.lttng.org wrote:
> - added verbose option to print traces
> - added sync-before-first-event to wait on file before first event
> - added help option
> - added missing short option "-e"
> - don't allow negative wait times
I don't think
- On Apr 1, 2021, at 12:37 PM, lttng-dev lttng-dev@lists.lttng.org wrote:
> the following tests fails
> - test_event_vpid_tracker ust 0 "${EVENT_NAME}"
> - test_event_vpid_track_untrack ust 0 "${EVENT_NAME}"
> - test_event_pid_tracker ust 0 "${EVENT_NAME}"
> - test_event_pid_track_untrack ust
1 - 100 of 303 matches
Mail list logo
