In the case of short lived applications, a race condition may occur before
the initial statedump is done and the end of the application. We force the
statedump to occur before handing the control to the application.
fixes #1190
Signed-off-by: Gabriel-Andrew Pollo-Guilbert
---
liblttng-ust/lttn
> From somewhere, I saw CPU cycles % with LTTng is even 1-2% lower than vanilla.
You might be referring to section 5.3 of [1], last paragraph.
[1] https://www.dorsal.polymtl.ca/en/system/files/desnoyers.pdf
In any cases, there is always an overhead when actively tracing (recording to
disk, netwo
Thanks Jonathan.
From somewhere, I saw CPU cycles % with LTTng is even 1-2% lower than vanilla.
Is it contributed by dynamic branch prediction or other instruction level
optimization?
In that way, the kernel or at least key libraries like libc is kind of
re-compiled, right?
Regards
Hai
---
Hi Martin,
On Thu, Jul 11, 2019 at 05:45:58PM +, Martin, Wilson wrote:
> So, this is mainly for a kernel function. Details below:
> unsigned int get_random_int(void);
>
> lttng enable-event get_random_int --kernel --function get_random_int
>
> get_random_int_entry: { cpu_id = 0 }, { pid = 22
Hi Hai,
On Tue, Jul 16, 2019 at 10:19:38AM +0800, 杨海 wrote:
> Obviously LTTng has much lower overhead compared to auditd, when we turn on
> all system calls and use the same load. Is it true for both user space and
> kernel space?
lttng-ust (userspace tracer) mostly use the same concept as the ke
Hi,
Obviously LTTng has much lower overhead compared to auditd, when we turn on all
system calls and use the same load. Is it true for both user space and kernel
space?
So far I haven't seen any report compare LTTng and auditd, anyone knows?
Regards
Hai
