Re: make TGID available also in binary ring buffer?

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

 



Hi Steve,

thank you for your answer,

On 3/13/19 2:44 PM, Steven Rostedt wrote:
> On Wed, 13 Mar 2019 09:26:33 +0100
> Claudio <claudio.fontana@xxxxxxxxx> wrote:
> 
> 
>> 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,
> 
> Currently save_cmdlines and saved_tgids are only in the top level
> tracing directory, and are global for all tracing.
> 
> Thinking about this a bit more, it does make sense to make this an
> instance file, as we don't want instance tracing to remove the top
> level cached cmdlines.
> 
>>
>> 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?
> 
> Well, forks and free can happen after tracing, and they are only
> updated during the trace. We mostly want to see the tasks when they
> run, and the sched_switch is the best place to save them.
> 
>>
>> 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.
> 
> You are reading this at the time of tracing?

Yes, my requirements are for live tracing of the low level events, and correlation of the events from all cores, in order to be able to immediately respond to the events from the tracing application.

Tracing is expected to be always on in the system (no expected trace-first/analyze later pattern - everything related to the analysis of the events is automated and occurs at runtime).

This works fine for the real time timing analysis at the thread level, but for the process level I need to know the tgid of the thread at the time I see the event.
 
>>
>> 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?
> 
> Currently, it's only taken at the end of the trace.

I wonder what the concept of the "end of the trace" is..

> 
> -- Steve

Thank you very much,

Claudio





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

  Powered by Linux