All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: "Yordan Karadzhov (VMware)" <y.karadz@gmail.com>
Cc: linux-kernel@vger.kernel.org, tglx@linutronix.de, peterz@infradead.org
Subject: Re: [PATCH v3 1/5] tracing: Define new ftrace event "func_repeats"
Date: Tue, 13 Apr 2021 20:33:59 -0400	[thread overview]
Message-ID: <20210413203359.322b902e@gandalf.local.home> (raw)
In-Reply-To: <20210413151736.36ec77eb@gandalf.local.home>

On Tue, 13 Apr 2021 15:17:36 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> Running this with trace-cmd record, this displays:
> 
>           <idle>-0     [001]   261.848848: function:                            next_zone
>           <idle>-0     [001]   261.848849: func_repeats:          next_zone <-need_update       (repeats:3  delta_ts: -189)
> 
> Which is confusing in a number of ways.
> 
> 1. It would be better to have it be the actual timestamp of the last repeat.
>    But that can be done in a trace-cmd plugin (like the function trace has).
> 
> 2. It should be "delta_ns:" because it is not -189 from the timestamp, as
>    the above time stamp is truncated to microseconds and this is not
>    obvious to the user.

After playing with this some more, I take back #2. As we don't know what
units the time stamp is actually in. As it is best to simply show the time
stamp of the last event where it matches the other time stamps (which we
can do, as I demonstrated in other emails), I think the best answer is to
leave the default ambiguous as simply "delta:". That way if it's not
processed, all you see is "delta: -189" and if people don't know what that
means, they'll either ignore it, or look up its meaning. I think both
"delta_ts" and "delta_ns" can be misleading if what is displayed does not
match the raw time stamps.

-- Steve

  parent reply	other threads:[~2021-04-14  0:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-09 18:10 [PATCH v3 0/5] Add "func_no_repete" tracing option Yordan Karadzhov (VMware)
2021-04-09 18:10 ` [PATCH v3 1/5] tracing: Define new ftrace event "func_repeats" Yordan Karadzhov (VMware)
2021-04-13 18:19   ` Steven Rostedt
2021-04-13 19:17   ` Steven Rostedt
2021-04-13 20:48     ` Steven Rostedt
2021-04-14  0:33     ` Steven Rostedt [this message]
2021-04-09 18:10 ` [PATCH v3 2/5] tracing: Add "last_func_repeats" to struct trace_array Yordan Karadzhov (VMware)
2021-04-13 18:31   ` Steven Rostedt
2021-04-09 18:10 ` [PATCH v3 3/5] tracing: Add method for recording "func_repeats" events Yordan Karadzhov (VMware)
2021-04-13 18:24   ` Steven Rostedt
2021-04-09 18:10 ` [PATCH v3 4/5] tracing: Unify the logic for function tracing options Yordan Karadzhov (VMware)
2021-04-09 18:10 ` [PATCH v3 5/5] tracing: Add "func_no_repeats" option for function tracing Yordan Karadzhov (VMware)

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=20210413203359.322b902e@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=y.karadz@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.