[lttng-dev] Tracing directly into shared memory

[Mathieu Desnoyers]

----- On Mar 4, 2019, at 4:28 AM, Thomas Schickentanz <thomas.schickentanz at harman.com> wrote: 

> Hi all,

> My idea is to pre-allocate memory on system startup which can later be used by
> lttng for tracing. It should work like flight recorder mode without extracting
> data from ringbuffers to trace file while recording data. Data extraction of
> shm ringbuffers should be done when recording has been finished.

> As per documention with option `--shm-path‘ ringbuffer for tracing can be
> created in shared memory. With lttng-crash data can be extracted from
> ringbuffer.

> Can this option be used with shared memory in volatile memory (default ram),
> too? And is it possible to record kernel space traces with this option?

> I tried

> lttng create testshm --shm-path=/dev/shm --snapshot

> lttng enable-channel c0 -s testshm -k

> lttng enable-event -s testshm -c c0 -k -a

> lttng start

> lttng stop

> lttng-crash -extract=/home/test /dev/shm

> With lttng and lttng-crash everything seems to work fine (no error messages).

> However the extract folder keeps empty.

> Has someone researched into this option and can help to clarify the points?

Hi Thomas, 

About "--shm-path" and lttng-crash, those are discussed here: [ https://lttng.org/docs/v2.10/#doc-persistent-memory-file-systems | https://lttng.org/docs/v2.10/#doc-persistent-memory-file-systems ] 

I'm not sure I completely understand your use-case and whether your intent is to extract trace data after a 
system crash or if the "snapshot" mode is enough for your needs. 

Note that the "shm-path" option only applies to UST (user-space) traces at the moment. It has not been implemented 
for kernel tracing yet. 

The way we typically use it for extraction of trace data from user-space when a system crashes is to use the pmem driver to 
create a block device out of a range of the system memory, and then use ext2 or ext4 with the DAX mount option to ensure 
the filesystem bypasses the page cache. 

Then we ensure that kexec is used to boot a new kernel on crash, or make sure the BIOS does not erase the 
memory content on soft reboot, which gives access to the shm-path buffers after crash/reboot. 

We don't usually use /dev/shm as an argument to --shm-path. This path is normally used to hold POSIX shared memory 
files. I would expect a different mount point path as argument to --shm-path which points to a DAX-enabled filesystem 
backed by a PMEM block device. 

Thanks, 

Mathieu 

-- 
Mathieu Desnoyers 
EfficiOS Inc. 
http://www.efficios.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20190304/f83c6eca/attachment.html>