The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Tim Bird <tim.bird@am.sony.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] tracing/function-branch-tracer: enhancements for the trace output
Date: Thu, 27 Nov 2008 15:13:31 +0100	[thread overview]
Message-ID: <20081127141331.GA28479@elte.hu> (raw)
In-Reply-To: <alpine.DEB.1.10.0811270905310.18691@gandalf.stny.rr.com>


* Steven Rostedt <rostedt@goodmis.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

  reply	other threads:[~2008-11-27 14:13 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-27  0:46 [PATCH] tracing/function-branch-tracer: enhancements for the trace output Frederic Weisbecker
2008-11-27  0:57 ` Frédéric Weisbecker
2008-11-27  1:08   ` Steven Rostedt
2008-11-27 12:53     ` Frédéric Weisbecker
2008-11-27 10:19 ` Peter Zijlstra
2008-11-27 14:53   ` Frédéric Weisbecker
2008-11-27 15:05     ` Ingo Molnar
2008-11-27 10:34 ` Ingo Molnar
2008-11-27 10:55   ` Peter Zijlstra
2008-11-27 11:29     ` Ingo Molnar
2008-11-27 13:18       ` Frédéric Weisbecker
2008-11-27 14:07       ` Steven Rostedt
2008-11-27 14:13         ` Ingo Molnar [this message]
2008-11-27 13:11     ` Frédéric Weisbecker
2008-11-27 14:03       ` Steven Rostedt
2008-11-27 13:06   ` Frédéric Weisbecker
2008-11-27 13:51     ` Ingo Molnar
2008-11-27 14:44       ` Frédéric Weisbecker
2008-11-27 14:46         ` Ingo Molnar
2008-11-27 14:58           ` Frédéric Weisbecker
2008-11-27 15:03             ` Ingo Molnar
2008-11-27 15:09               ` Frédéric Weisbecker
2008-11-27 15:31         ` Steven Rostedt
2008-11-27 15:51           ` Frédéric Weisbecker
2008-11-28 13:05           ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081127141331.GA28479@elte.hu \
    --to=mingo@elte.hu \
    --cc=a.p.zijlstra@chello.nl \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tim.bird@am.sony.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox