Multiple Tracing Events Readers

Question

Question

Does the tracing pipes in Linux, for tracing events, accepts simultaneous readers?

Context

I am trying to get traces from the RAS subsystem while running some benchmarks. This subsystem reports hardware error events using trace events.

The tool I am using to get the events in the RASdaemon tool. I know the tool subscribe to the tracing_pipe_raw FIFO on each cpu. Furthermore, the benchmark subscribe to performance events which, I believe that, are also advertised through the same pipes.

The tracing_pipe_raw works like the trace_pipe which has the following description:

The output is the same as the “trace” file but this file is meant to be streamed with live tracing. Reads from this file will block until new data is retrieved. Unlike the “trace” file, this file is a consumer. This means reading from this file causes sequential reads to display more current data. Once data is read from this file, it is consumed, and will not be read again with a sequential read. The “trace” file is static, and if the tracer is not adding more data, it will display the same information every time it is read. Unlike the “trace” file, opening this file for reading will not temporarily disable tracing.

I understand the concept of FIFO being a consumer file and why each read will produce different data. However, do the Kernel make any arrangements for multiple subscribers (reader) to these events?

Answer 1

I figured out that simultaneous readers accessing the tracing pipes will interfere with each other.

If you want to avoid this behavior, you should create a folder in the instances directory in the tracing pipes. If you do so, the Linux kernel will automatically create a copy of the tracing pipes in your new directory.

The new instance can be configured almost completely independent from the main tracing pipes and other instances. More information about this can be found here: Instances at Tracing Pipes Technologies

For those wondering about Rasdaemon, it does create its own instance so you can safely employ other readers in the pipes. Although I would recommend creating other instances for your readers if you think there might be other trace consumers.