From: Jiejing Zhang <[email protected]>
ftrace only report pid in task switch event, which is
actually thread ID in user space view, the comm of
the thread will be like "Thread-1", "Compiler", etc
in android system, it's useful if we can add tgid
information in ftrace event to find out the process
id, and the process id's comm will help us to figure
out the application, which was useful on data analysis
tools.
Change-Id: Ia99f58a56d691d770b3beb2f76de0351e6194a4a
Signed-off-by: Jiejing Zhang <[email protected]>
---
include/trace/events/sched.h | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
index e5586ca..3fbcddb 100644
--- a/include/trace/events/sched.h
+++ b/include/trace/events/sched.h
@@ -124,32 +124,37 @@ TRACE_EVENT(sched_switch,
TP_STRUCT__entry(
__array( char, prev_comm, TASK_COMM_LEN )
__field( pid_t, prev_pid )
+ __field( pid_t, prev_tgid )
__field( int, prev_prio )
__field( long, prev_state )
__array( char, next_comm, TASK_COMM_LEN )
__field( pid_t, next_pid )
+ __field( pid_t, next_tgid )
__field( int, next_prio )
),
TP_fast_assign(
memcpy(__entry->next_comm, next->comm, TASK_COMM_LEN);
__entry->prev_pid = prev->pid;
+ __entry->prev_tgid = prev->tgid;
__entry->prev_prio = prev->prio;
__entry->prev_state = __trace_sched_switch_state(prev);
memcpy(__entry->prev_comm, prev->comm, TASK_COMM_LEN);
__entry->next_pid = next->pid;
+ __entry->next_tgid = next->tgid;
__entry->next_prio = next->prio;
),
- TP_printk("prev_comm=%s prev_pid=%d prev_prio=%d prev_state=%s%s ==> next_comm=%s next_pid=%d next_prio=%d",
- __entry->prev_comm, __entry->prev_pid, __entry->prev_prio,
+ TP_printk("prev_comm=%s prev_pid=%d prev_tgid=%d prev_prio=%d prev_state=%s%s ==> next_comm=%s next_pid=%d next_tgid=%d next_prio=%d",
+ __entry->prev_comm, __entry->prev_pid,
+ __entry->prev_tgid, __entry->prev_prio,
__entry->prev_state & (TASK_STATE_MAX-1) ?
- __print_flags(__entry->prev_state & (TASK_STATE_MAX-1), "|",
+ __print_flags(__entry->prev_state & (TASK_STATE_MAX-1), "|",
{ 1, "S"} , { 2, "D" }, { 4, "T" }, { 8, "t" },
{ 16, "Z" }, { 32, "X" }, { 64, "x" },
{ 128, "K" }, { 256, "W" }, { 512, "P" }) : "R",
__entry->prev_state & TASK_STATE_MAX ? "+" : "",
- __entry->next_comm, __entry->next_pid, __entry->next_prio)
+ __entry->next_comm, __entry->next_pid, __entry->next_tgid, __entry->next_prio)
);
/*
--
1.8.1.5
This patch needs to be decided by Peter.
Also, the subject should not read "ftrace:" it should have "sched:" as
tracepoints are the property of the subsystem they exist in, not the
tracing facility itself, as it's not just ftrace that uses tracepoints.
-- Steve
On Wed, 21 Aug 2013 15:05:20 +0000
Jiejing Zhang <[email protected]> wrote:
> From: Jiejing Zhang <[email protected]>
>
> ftrace only report pid in task switch event, which is
> actually thread ID in user space view, the comm of
> the thread will be like "Thread-1", "Compiler", etc
> in android system, it's useful if we can add tgid
> information in ftrace event to find out the process
> id, and the process id's comm will help us to figure
> out the application, which was useful on data analysis
> tools.
>
> Change-Id: Ia99f58a56d691d770b3beb2f76de0351e6194a4a
> Signed-off-by: Jiejing Zhang <[email protected]>
> ---
> include/trace/events/sched.h | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
> index e5586ca..3fbcddb 100644
> --- a/include/trace/events/sched.h
> +++ b/include/trace/events/sched.h
> @@ -124,32 +124,37 @@ TRACE_EVENT(sched_switch,
> TP_STRUCT__entry(
> __array( char, prev_comm, TASK_COMM_LEN )
> __field( pid_t, prev_pid )
> + __field( pid_t, prev_tgid )
> __field( int, prev_prio )
> __field( long, prev_state )
> __array( char, next_comm, TASK_COMM_LEN )
> __field( pid_t, next_pid )
> + __field( pid_t, next_tgid )
> __field( int, next_prio )
> ),
>
> TP_fast_assign(
> memcpy(__entry->next_comm, next->comm, TASK_COMM_LEN);
> __entry->prev_pid = prev->pid;
> + __entry->prev_tgid = prev->tgid;
> __entry->prev_prio = prev->prio;
> __entry->prev_state = __trace_sched_switch_state(prev);
> memcpy(__entry->prev_comm, prev->comm, TASK_COMM_LEN);
> __entry->next_pid = next->pid;
> + __entry->next_tgid = next->tgid;
> __entry->next_prio = next->prio;
> ),
>
> - TP_printk("prev_comm=%s prev_pid=%d prev_prio=%d prev_state=%s%s ==> next_comm=%s next_pid=%d next_prio=%d",
> - __entry->prev_comm, __entry->prev_pid, __entry->prev_prio,
> + TP_printk("prev_comm=%s prev_pid=%d prev_tgid=%d prev_prio=%d prev_state=%s%s ==> next_comm=%s next_pid=%d next_tgid=%d next_prio=%d",
> + __entry->prev_comm, __entry->prev_pid,
> + __entry->prev_tgid, __entry->prev_prio,
> __entry->prev_state & (TASK_STATE_MAX-1) ?
> - __print_flags(__entry->prev_state & (TASK_STATE_MAX-1), "|",
> + __print_flags(__entry->prev_state & (TASK_STATE_MAX-1), "|",
> { 1, "S"} , { 2, "D" }, { 4, "T" }, { 8, "t" },
> { 16, "Z" }, { 32, "X" }, { 64, "x" },
> { 128, "K" }, { 256, "W" }, { 512, "P" }) : "R",
> __entry->prev_state & TASK_STATE_MAX ? "+" : "",
> - __entry->next_comm, __entry->next_pid, __entry->next_prio)
> + __entry->next_comm, __entry->next_pid, __entry->next_tgid, __entry->next_prio)
> );
>
> /*
On Wed, Aug 21, 2013 at 11:09:44AM -0400, Steven Rostedt wrote:
> > From: Jiejing Zhang <[email protected]>
> >
> > ftrace only report pid in task switch event, which is
> > actually thread ID in user space view, the comm of
> > the thread will be like "Thread-1", "Compiler", etc
> > in android system, it's useful if we can add tgid
> > information in ftrace event to find out the process
> > id, and the process id's comm will help us to figure
> > out the application, which was useful on data analysis
> > tools.
Meh.. are you telling me you really can't do that otherwise?
Adding this information makes the tracepoint slower for everybody else.
How about you enable trace_sched_process_fork() and track things that
way?
Also, last time I tried to change one of these stupid tracepoints
userspace broke.. Rostedt says people should be using libtraceevent but
I'm sceptical.
> > Change-Id: Ia99f58a56d691d770b3beb2f76de0351e6194a4a
That needs to die.
On 08/21/2013 11:23 PM, Peter Zijlstra wrote:
> On Wed, Aug 21, 2013 at 11:09:44AM -0400, Steven Rostedt wrote:
>>> From: Jiejing Zhang <[email protected]>
>>>
>>> ftrace only report pid in task switch event, which is
>>> actually thread ID in user space view, the comm of
>>> the thread will be like "Thread-1", "Compiler", etc
>>> in android system, it's useful if we can add tgid
>>> information in ftrace event to find out the process
>>> id, and the process id's comm will help us to figure
>>> out the application, which was useful on data analysis
>>> tools.
> Meh.. are you telling me you really can't do that otherwise?
>
> Adding this information makes the tracepoint slower for everybody else.
> How about you enable trace_sched_process_fork() and track things that
> way?
Thanks for the tip, I have tried fix this by avoid add tgid in ftrace,
actually the relationship between thread and process can be figure by
analysis these two command's output:
`ps aTH -F` and `ps a -F`
also with fork event, it can totally avoid add such a patch in kernel.
Thanks.
>
> Also, last time I tried to change one of these stupid tracepoints
> userspace broke.. Rostedt says people should be using libtraceevent but
> I'm sceptical.
>
>>> Change-Id: Ia99f58a56d691d770b3beb2f76de0351e6194a4a
> That needs to die.
On Fri, Aug 23, 2013 at 04:33:19PM +0800, Jiejing Zhang wrote:
>
> On 08/21/2013 11:23 PM, Peter Zijlstra wrote:
> >On Wed, Aug 21, 2013 at 11:09:44AM -0400, Steven Rostedt wrote:
> >>>From: Jiejing Zhang <[email protected]>
> >>>
> >>>ftrace only report pid in task switch event, which is
> >>>actually thread ID in user space view, the comm of
> >>>the thread will be like "Thread-1", "Compiler", etc
> >>>in android system, it's useful if we can add tgid
> >>>information in ftrace event to find out the process
> >>>id, and the process id's comm will help us to figure
> >>>out the application, which was useful on data analysis
> >>>tools.
> >Meh.. are you telling me you really can't do that otherwise?
> >
> >Adding this information makes the tracepoint slower for everybody else.
> >How about you enable trace_sched_process_fork() and track things that
> >way?
> Thanks for the tip, I have tried fix this by avoid add tgid in ftrace,
> actually the relationship between thread and process can be figure by
> analysis these two command's output:
> `ps aTH -F` and `ps a -F`
Yeah, or prod around in /proc yourself.
> also with fork event, it can totally avoid add such a patch in kernel.
Kinda depends on when you start tracing, if you start tracing when
everything is already running you'll need a /proc state dump for the
current state and the fork tracepoint can then update you on new tasks.
Anyway, good to hear this works for you.