Re: make TGID available also in binary ring buffer?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 3/4/19 7:51 PM, Steven Rostedt wrote:
> On Mon, 4 Mar 2019 11:01:39 +0100
> Claudio <claudio.fontana@xxxxxxxxx> wrote:
> 
>> Hello all,
>>
>> I am currently facing the issue of having to efficiently read the events
>> from a user-space application for tracing for programmatic use in automotive
>> (AUTOSAR AP).
>>
>> It is for programmatically reacting to events on the system,
>> and I am currently using the trace_pipe_raw to do that, to reduce the
>> overhead compared with parsing the textual output of trace_pipe.
>>
>> After merging the sorted streams from all cpus, in order to reconstruct
>> the task state, we are still way more CPU-efficient compared with using the
>> textual output.
>>
>> I would like to make use of the implemented support for recording tgids,
>>
>> commit d914ba37d714 ("tracing: Add support for recording tgid of tasks")
>> commit 441dae8f2f29 ("tracing: Add support for display of tgid in trace output")
>>
>> but it seems to me that, while for COMM recording there is explicit support in
>> the binary events for the information, it seems that tgid is not stored in the
>> binary format.
>>
>> Is such an extension of the binary format a possibility for sched-class
>> events, that takes into account backward compatibility, or is there some
>> better way to do it? Is this problem addressed by libtracevent / trace-cmd?
>>
>> Currently I was thinking to look into the NETLINK interface to get the task
>> information, however the issue is the race condition between the time of
>> tracing and the time of reading the trace, to be fully correct, but if
>> nothing else is possible I will have to accept the compromise.
>>
>> Thank you for any hints on this.
> 
> It looks to be outputted into /sys/kernel/debug/tracing/saved_tgids
> 
> Interesting, we should probably save that in trace-cmd as well.
> 
> -- Steve
> 

Hi Steve,

I have two questions regarding saved_tgids which are currently blocking and confusing me.

1) Are the saved_tgids not present in a tracing instance?
I am currently interacting with ftrace from the application doing everything in an instance,

tracefs on /usr/local/var/run/T1/tracing type tracefs (rw,relatime)

but the saved_tgids is not present in my instance directory.

2) Which state does "saved_tgids" represent, ie when is it updated?

The ftrace.rst doc says at each context switch, but wouldn't sched_process_fork / sched_process_free tracepoints be a better place to update?

When I read an event for a new process or thread (sched_process_fork),
I need to know if it is a new thread or a new process at that time, and collect the tgid of the child.

How can I get that information, if the update is done only at the time of the first "child" context-switch?

3) Is the saved_tgids map in sync with the reader of trace_pipe_raw,
so that when reading an event from the pipe, the saved_tgids represent the particular state of the tid to tgid maps at the timestamp indicated in the event?

Or is the saved_tgids map updated asynchronously with the reader?

Thank you for any advice on this..

Ciao,

Claudio



[Index of Archives]     [Linux USB Development]     [Linux USB Development]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux