Re: make TGID available also in binary ring buffer?

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

 



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?

> 
> 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.

-- Steve

> 
> 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