Re: [RFC] adding of TGID to ftrace output

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 10 May 2017 16:04:55 -0700
Joel Fernandes <joelaf@google.com> wrote:

> Hi Steven,
> 
> Can we add TGID information along with PID to ftrace output?
> 
> Something like:
> #                                   _-----=> irqs-off
> #                                  / _----=> need-resched
> #                                 | / _---=> hardirq/softirq
> #                                 || / _--=> preempt-depth
> #                                 ||| /     delay
> #           TASK-PID:TGID   CPU#  ||||    TIMESTAMP  FUNCTION
> #              | |     |      |   ||||       |         |
>             bash-1977:1977  [000] .... 17284.993652: sys_close <-
> 
> Instead of:
> #                              _-----=> irqs-off
> #                             / _----=> need-resched
> #                            | / _---=> hardirq/softirq
> #                            || / _--=> preempt-depth
> #                            ||| /     delay
> #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
> #              | |       |   ||||       |         |
>             bash-1977  [000] .... 17284.993652: sys_close <-

Well the thing about this is that it adds more overhead to each event
that is mostly not needed by users.

> 
> Currently in android, we inject tgid into each trace event at the end
> of the trace just so we can group threads under a process in our trace
> viewer.
> 
> The other option we're thinking off is we can retrieve tgid during the
> trace output (reading trace file from debugfs/tracefs) from the
> task_struct and then have ftrace output it that way.

Hmm, is there any events that show the TGID currently? If we have that,
you can use another tracing instance to read from (one that wont get
overridden by other events), and keep track of what TGID processes
have. The timestamp could be used to keep everything in sync.

> 
> Anyway, having this will really simplify things and make it more
> reliable (we run ps -T at the end of the trace right now, but its
> unreliable because threads might have exited by then). We also have to
> call getpid() and inject pid into each userspace trace_marker write
> just so we can do this grouping.

Perhaps we need to have a way to record it via another event. Fork or
sched switch?

Perhaps we can add a trigger to record extra data like this, similar to
the stack trace trigger does now.

Also, you could add a kprobe at sched switch or something to possibly
record this.

-- Steve