[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210413203359.322b902e@gandalf.local.home>
Date: Tue, 13 Apr 2021 20:33:59 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: "Yordan Karadzhov (VMware)" <y.karadz@...il.com>
Cc: linux-kernel@...r.kernel.org, tglx@...utronix.de,
peterz@...radead.org
Subject: Re: [PATCH v3 1/5] tracing: Define new ftrace event "func_repeats"
On Tue, 13 Apr 2021 15:17:36 -0400
Steven Rostedt <rostedt@...dmis.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
Powered by blists - more mailing lists