[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081127141331.GA28479@elte.hu>
Date: Thu, 27 Nov 2008 15:13:31 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Frederic Weisbecker <fweisbec@...il.com>,
Tim Bird <tim.bird@...sony.com>,
Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] tracing/function-branch-tracer: enhancements for the
trace output
* Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Thu, 27 Nov 2008, Ingo Molnar wrote:
>
> >
> > mockup:
> >
> > ----------------------------------------------------------------
> > CPU) task-PID | cost | function
> > ----------------------------------------------------------------
> >
> > 0) bash-54320 | | sys_read() {
> > 0) bash-54320 | 0.331 us | fget_light();
> > 0) bash-54320 | | vfs_read() {
> > 0) mycomman-1234 | | rw_verify_area() {
> > 0) mycomman-1234 | 121.444 us | func();
> >
> > Note some details:
> >
> > 1) longer comm names can be stripped off at 7 chars - 7 chars is
> > enough to recognize most of the things and the PID is good enough
> > for extra separation)
> >
> > 2) the ssssssss-12345 task identifier is _center_ aligned. It's a rare
> > alignment case but useful here: most people look at the command
> > portion and the whole string must be greppable and useful in traces
> > as an identifier - so right-aligning the PID is not a good
> > solution.
> >
> > 3) there's vertical separation after the task portion as well. This
> > helps us ignore the task portion when we want to look at only the
> > code and the cost of it. (the common case)
> >
> > > comm/pid only in the separator is useless, you cannot grep stuff
> > > like that, also, what's up with those '8's ?
> >
> > yeah, that context-switch separator is horrible.
> >
> > We can keep the separator, but as something saner, like:
> >
> > ---------------------------------------------------------
> > CPU) cost | function
> > ---------------------------------------------------------
> >
> > 0) | sys_read() {
> > 0) 0.331 us | fget_light();
> > 0) | vfs_read() {
> > 0) | rw_verify_area() {
> > 0) | security_file_permission() {
> > 0) 0.306 us | cap_file_permission();
> > 0) 0.300 us | cap_file_permission();
> > 0) 8.909 us | }
> > 0) 0.993 us | }
> > 0) 11.649 us | }
> > 0) | do_sync_read() {
> > . -------------------------
> > 0) ==> [ bash-2794 => cat-1234 ]
> > -------------------------
> >
> > 0) | __sock_recvmsg() {
> > 0) | security_socket_recvmsg() {
> > 0) 100.319 us | cap_socket_recvmsg();
> > ---------------------------------------------------------
>
> Yes please. I like the separator better. Sure, we could add a trace_option
> that will let us print the name on all lines, which will make it grepable
> better. But this is better to see when the switch happens.
>
> Also, Frederic could use my ftrace_trace_pid to filter only on a
> single thread. But that will need to wait till we figure out this
> namespace issue.
Note that your PID filter is in tip/tracing/core already, so Frederic
can make use of it if he wishes to. Changing it to struct pid
(whenever that happens) will not change its functionality.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists