[lttng-dev] 回复:Re: Pros and Cons of LTTng
杨海
hai.yang at magic-shield.com
Tue Jul 16 10:50:40 EDT 2019
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
--------------原始邮件--------------
发件人:"Jonathan Rajotte-Julien "<jonathan.rajotte-julien at efficios.com>;
发送时间:2019年7月16日(星期二) 晚上10:28
收件人:"杨海" <hai.yang at magic-shield.com>;
抄送:"lttng-dev "<lttng-dev at lists.lttng.org>;
主题:Re: [lttng-dev] Pros and Cons of LTTng
-----------------------------------
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 kerneltracer
(per-cpu ring buffers, binary output/CTF, delayed consumption of events, etc.).
There is some penalty for doing things in userspace since we need some
information from the kernel for each tracepoint hit (e.g the current cpu
number). But again most of these hot paths are quite optimized.
In any case I encourage you to try it out on your workload and lttng fit your
needs.
If you do not find a particular feature in the doc [1], do not hesitate to contact
this mailing list for more information.
>So far I haven't seen any report compare LTTng and auditd,
> anyone knows?
I do not remember any conversation on this topic. After reading a bit on auditd,
lttng might be a good replacement depending on your constraints and needs.
[1] https://lttng.org/docs/v2.10/
Cheers
--
Jonathan Rajotte-Julien
EfficiOS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20190716/515424ba/attachment-0001.html>
More information about the lttng-dev
mailing list