From: <Viktor.Rosendahl@bmw.de>
To: <rostedt@goodmis.org>
Cc: <linux-trace-devel@vger.kernel.org>
Subject: Re: Adding latency tracking to trace-cmd
Date: Wed, 24 Feb 2021 19:22:48 +0000 [thread overview]
Message-ID: <e1c4952249578eea44817d092bffe27fd0e47645.camel@bmw.de> (raw)
In-Reply-To: <20210224115408.1c76ee3f@gandalf.local.home>
Hi Steve,
On Wed, 2021-02-24 at 11:54 -0500, Steven Rostedt wrote:
> Hi Viktor,
>
> While doing some tests to trace-cmd, I found that the trace-cmd record was
> broken for latency tracers, and has been for some time. That's probably
> because nobody has been using it for such.
>
> That is, trace-cmd record is mostly used for "flyrecord" which is the
> constant recording of tracing. But if the user records one of the latency
> tracers (preemptirqsoff, wakeup_rt, etc), then it switches to "latency"
> mode and only takes a snapshot at the end of the recording. This is what I
> found to be broken, because it reset the tracing before taking the
> snapshot and lost whatever it was recording. Nobody seemed to complain
> about it, so I guess nobody cared.
>
I have used trace-cmd but I did not know about this feature. Somehow I had
assumed that trace-cmd would not deal with those tracers that work in overwrite
mode.
> The fix is simple, and I was about to do so, but then I thought about your
> latency-collector tool, and thought that should be exactly what trace-cmd
> should do for such tracers. That is, instead of just taking a snapshot of
> the latency at the end of the recording (which it was suppose to do now),
> it should act like your latency-collector tool, and take snapshots
> every time there's a new latency.
>
> My question to you is, would you like to work on adding that feature to
> trace-cmd?
I would be interested to work on the feature but I would probably need
permission from my employer, also in case I do it as a spare time project.
For this reason, I will need some time come to a decision. I will get back to
you when I know the answer.
>
> git://git.kernel.org/pub/scm/utils/trace-cmd/trace-cmd.git
>
> (which requires the libtracefs and libtracevent libraries).
>
> I'm thinking if someone were to do:
>
> trace-cmd record -p wakeup_rt
>
> It would then act just like the latency-collector and record every new
> instance of a latency into the trace.dat file, where:
>
> trace-cmd report
>
> would then nicely format that data for the user.
>
> Thoughts?
It seems like trace-cmd is mostly GPL-2.0. The latency-collector is also GPL-
2.0, so I guess that it would be possible to take snippets of code and
inspiration from it.
Would you allow the hackish random algorithm to be used in trace-cmd?
I mean the "--random" option in latency-collector.
best regards,
Viktor
>
> -- Steve
next prev parent reply other threads:[~2021-02-24 19:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-24 16:54 Adding latency tracking to trace-cmd Steven Rostedt
2021-02-24 19:22 ` Viktor.Rosendahl [this message]
2021-02-24 20:10 ` Steven Rostedt
2021-04-06 17:38 ` Steven Rostedt
2021-04-06 20:03 ` Viktor.Rosendahl
2021-04-06 20:24 ` Viktor.Rosendahl
2021-04-06 20:42 ` Steven Rostedt
2021-04-08 21:01 ` Viktor Rosendahl
2021-04-08 21:17 ` Steven Rostedt
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=e1c4952249578eea44817d092bffe27fd0e47645.camel@bmw.de \
--to=viktor.rosendahl@bmw.de \
--cc=linux-trace-devel@vger.kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).