lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ