----- On Jul 23, 2019, at 9:27 PM, Jonathan Rajotte jonathan.rajotte-jul...@efficios.com wrote:
> CC'ing the mailing list back. > > On Tue, Jul 23, 2019 at 03:58:09PM -0400, Yiteng Guo wrote: >> Hi Jonathan, >> >> Thank you for the patch! It is really helpful. > > Were you able to observe a positive impact? > > This is something we might be interested in upstreaming if we have good > feedback. > >> >> Is there any disadvantage of per-pid buffering? I don't want to have >> processes interfere with each other so I choose per-pid buffering. > > The main downside is that each registered applications will get their own > subbuffers resulting in a lot of memory usage depending on your session > configuration. This can get out of hand quickly, especially on systems withs > lots > of cores and unknown number of instrumented applications. I can add 2 extra cents (or actually a few more) to this answer: There are a few reasons for using per-uid buffers over per-pid: - Lower memory consumption for use-cases with many processes, - Faster process launch time: no need to allocate buffers for each process. Useful for use-cases with short-lived processes. - Keep a flight recorder "snapshot" available for all processes, including those which recently exited. Indeed, the per-pid buffers don't stay around for snapshot after a process exits or is killed. There are however a few advantages for per-pid buffers: - Isolation: if one PID generates corrupted trace data, it does not interfere with other PIDs buffers, - If one PID is killed between reserve and commit, it does not make that specific per-cpu ring buffer unusable for the rest of the tracing session lifetime. Hoping this information helps making the right choice for your deployment! Thanks, Mathieu > > If you completely control the runtime, for example when doing benchmarking or > simple analysis, feel free to use what make more sense to you as long as you > understand the pitfalls of each mode. > > Cheers > > -- > Jonathan Rajotte-Julien > EfficiOS > _______________________________________________ > 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