linux-trace-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Claudio <claudio.fontana@gliwa.com>
Cc: joel@joelfernandes.org,
	"linux-trace-devel@vger.kernel.org" 
	<linux-trace-devel@vger.kernel.org>, Chunyu Hu <chuhu@redhat.com>
Subject: Re: make TGID available also in binary ring buffer?
Date: Mon, 4 Mar 2019 13:51:47 -0500	[thread overview]
Message-ID: <20190304135147.5fcc243f@gandalf.local.home> (raw)
In-Reply-To: <6e61f5ff-5302-ad96-66d3-38347bf3cf69@gliwa.com>

On Mon, 4 Mar 2019 11:01:39 +0100
Claudio <claudio.fontana@gliwa.com> wrote:

> Hello all,
> 
> I am currently facing the issue of having to efficiently read the events
> from a user-space application for tracing for programmatic use in automotive
> (AUTOSAR AP).
> 
> It is for programmatically reacting to events on the system,
> and I am currently using the trace_pipe_raw to do that, to reduce the
> overhead compared with parsing the textual output of trace_pipe.
> 
> After merging the sorted streams from all cpus, in order to reconstruct
> the task state, we are still way more CPU-efficient compared with using the
> textual output.
> 
> I would like to make use of the implemented support for recording tgids,
> 
> commit d914ba37d714 ("tracing: Add support for recording tgid of tasks")
> commit 441dae8f2f29 ("tracing: Add support for display of tgid in trace output")
> 
> but it seems to me that, while for COMM recording there is explicit support in
> the binary events for the information, it seems that tgid is not stored in the
> binary format.
> 
> Is such an extension of the binary format a possibility for sched-class
> events, that takes into account backward compatibility, or is there some
> better way to do it? Is this problem addressed by libtracevent / trace-cmd?
> 
> Currently I was thinking to look into the NETLINK interface to get the task
> information, however the issue is the race condition between the time of
> tracing and the time of reading the trace, to be fully correct, but if
> nothing else is possible I will have to accept the compromise.
> 
> Thank you for any hints on this.

It looks to be outputted into /sys/kernel/debug/tracing/saved_tgids

Interesting, we should probably save that in trace-cmd as well.

-- Steve

  reply	other threads:[~2019-03-04 18:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-04 10:01 make TGID available also in binary ring buffer? Claudio
2019-03-04 18:51 ` Steven Rostedt [this message]
2019-03-13  8:26   ` Claudio
2019-03-13 13:44     ` Steven Rostedt
2019-03-13 14:03       ` Claudio
2019-03-13 14:50         ` Steven Rostedt
2019-03-14 16:06           ` Claudio
2019-03-14 18:20             ` Steven Rostedt
2019-03-14 21:40               ` Claudio

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=20190304135147.5fcc243f@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=chuhu@redhat.com \
    --cc=claudio.fontana@gliwa.com \
    --cc=joel@joelfernandes.org \
    --cc=linux-trace-devel@vger.kernel.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).