linux-trace-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).