mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Frédéric Weisbecker" <fweisbec@gmail.com>
To: "Ingo Molnar" <mingo@elte.hu>
Cc: "Steven Rostedt" <rostedt@goodmis.org>,
	"Linux Kernel" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] tracing/function-return-tracer: Call prepare_ftrace_return by registers
Date: Fri, 14 Nov 2008 00:48:14 +0100	[thread overview]
Message-ID: <c62985530811131548i176af7e4k2d3b8300f7c425f@mail.gmail.com> (raw)
In-Reply-To: <20081113100938.GA24602@elte.hu>

2008/11/13 Ingo Molnar <mingo@elte.hu>:
>
> * Frédéric Weisbecker <fweisbec@gmail.com> wrote:
>
>> That's right, it's much more better for the eyes. I didn't want to
>> output such a disposition from the kernel because I thought that
>> would result in too much strings work from kernel-space. But
>> actually, as you suggest,
>>  if I append a depth field in the trace that could be easy and not
>> so costly. I just have a last thought about post-processing parsing.
>> Would it make it harder for that?
>
> humans are the priority targets for tracer output - tools are a
> distant second target. Whatever is nice for humans is also usually
> easy to process via tools. A tool can set an option flag just fine.
>
> To help tooling, add a trace_options flag for more predictable/faster
> output. We already have the binary output format for example.
>
>> Why not a flag that could be set through iter_ctrl (which has
>> changed its name yesterday) and that could let the user to choose
>> its output? That's where I renew my proposition to make the tracers
>> able to propose custom flags for this file with a new callback such
>> as tracer_ctrl, or tracer_opt.
>
> yes, your proposal is fine.
>
>> But as you say, why not set it through a flag.
>
> yes - and make the defaults for flags favor human visual parsing.
>
>> > Easiest would be to add a depth field to the trace entry as well, to
>> > make sure we get the right depth in the end, even if we somehow mix up
>> > the trace entries.
>>
>> Yeah, that's good! I will just have to output "\t" * depth to have
>> the correct indentation.
>
> i'd suggest spaces for the function indentation, because we'll also
> have quite deep call stacks in practice.
>
> and i'd suggest you flip around the cost field to something like:
>
>  [...]
>               getnstimeofday() {
>                set_normalized_timespec() {
>                 clocksource_read() {
>  ( 1547 ns)       acpi_pm_read()
>  ( 1951 ns)      } clocksource_read()
>  ( 2200 ns)     } set_normalized_timespec()
>  ( 2354 ns)    } getnstimeofday()
>
> that makes it fixed-width up to the inevitable variable-length field,
> the function name.
>
>        Ingo
>

Ok, I will add all of these in my workqueue. Thanks :)

  reply	other threads:[~2008-11-13 23:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-12 21:49 Frederic Weisbecker
2008-11-12 22:16 ` Ingo Molnar
2008-11-12 22:22   ` Frédéric Weisbecker
2008-11-12 23:25     ` Steven Rostedt
2008-11-12 23:35       ` Frédéric Weisbecker
2008-11-13  0:11         ` Steven Rostedt
2008-11-13  8:59           ` Ingo Molnar
2008-11-13  9:14             ` Ingo Molnar
2008-11-13 10:02               ` Frédéric Weisbecker
2008-11-13 10:09                 ` Ingo Molnar
2008-11-13 23:48                   ` Frédéric Weisbecker [this message]
2008-11-13  9:38             ` Frédéric Weisbecker
2008-11-13  9:40               ` Frédéric Weisbecker
2008-11-13  9:44               ` Ingo Molnar
2008-11-17 18:58                 ` Frederic Weisbecker

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=c62985530811131548i176af7e4k2d3b8300f7c425f@mail.gmail.com \
    --to=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    /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

all inboxes | Powered by JetHome®