On Wed, 13 Mar 2019 15:03:35 +0100 Claudio <claudio.fontana@xxxxxxxxx> wrote: > >> > >> 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). You could add a kprobe to find out the tgid as well. > > 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.. I meant for "trace-cmd record", the saved_cmdlines are stored when the tracing is finished, not during the trace. But the saved_cmdlines is updated at each sched_switch, and so is the tgid. Now, we could add that info to the fork part as well. -- Steve
|