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: Thu, 14 Mar 2019 14:20:34 -0400	[thread overview]
Message-ID: <20190314142034.35469af8@gandalf.local.home> (raw)
In-Reply-To: <5cfad70b-b823-e3ed-630e-d766cc53f6e5@gliwa.com>

On Thu, 14 Mar 2019 17:06:11 +0100
Claudio <claudio.fontana@gliwa.com> wrote:

> Hi Steve,
> 
> I have experimented with mainline, and then with mainline plus a patch to add the info for fork as well like this:
> 
> diff --git a/kernel/trace/trace_sched_switch.c b/kernel/trace/trace_sched_switch.c
> index e288168..c5339ed 100644
> --- a/kernel/trace/trace_sched_switch.c
> +++ b/kernel/trace/trace_sched_switch.c
> @@ -47,6 +47,20 @@ probe_sched_wakeup(void *ignore, struct task_struct *wakee)
>  	tracing_record_taskinfo(current, flags);
>  }
>  
> +static void
> +probe_sched_fork(void *ignore,
> +		 struct task_struct *parent, struct task_struct *child)
> +{
> +	int flags;
> +
> +	flags = (RECORD_TGID * !!sched_tgid_ref) +
> +		(RECORD_CMDLINE * !!sched_cmdline_ref);
> +
> +	if (!flags)
> +		return;
> +	tracing_record_taskinfo(child, flags);
> +}
> +
>  static int tracing_sched_register(void)
>  {
>  	int ret;
> @@ -72,7 +86,16 @@ static int tracing_sched_register(void)
>  		goto fail_deprobe_wake_new;
>  	}
>  
> +	ret = register_trace_sched_process_fork(probe_sched_fork, NULL);
> +	if (ret) {
> +		pr_info("sched trace: Couldn't activate tracepoint"
> +			" probe to kernel_sched_process_fork\n");
> +		goto fail_deprobe_switch;
> +	}
> +
>  	return ret;
> +fail_deprobe_switch:
> +	unregister_trace_sched_switch(probe_sched_switch, NULL);
>  fail_deprobe_wake_new:
>  	unregister_trace_sched_wakeup_new(probe_sched_wakeup, NULL);
>  fail_deprobe:
> @@ -82,6 +105,7 @@ static int tracing_sched_register(void)
>  
>  static void tracing_sched_unregister(void)
>  {
> +	unregister_trace_sched_process_fork(probe_sched_fork, NULL);
>  	unregister_trace_sched_switch(probe_sched_switch, NULL);
>  	unregister_trace_sched_wakeup_new(probe_sched_wakeup, NULL);
>  	unregister_trace_sched_wakeup(probe_sched_wakeup, NULL);
> 
> 
> --
> 
> It seems to work, but the model seems not to apply very well to my use case.
> 
> saved_tgids cannot be reset, not even by disabling tracing completely
> 
> echo 0 > tracing_on
> 
> or 
> 
> echo 0 > options/record-tgids
> 
> and the list just keeps growing, no entries are ever removed when tasks are destroyed etc,
> so my lookups become more and more expensive as the list grows.
> I don't think this is suited to be looked up frequently for my tracing scenario.
> 

It shouldn't grow when you disable tracing though.

Hmm, we could add a reset if one writes to the saved_* files.

> Next I will experiment with:
> 
> 1) kprobes, trying to generate an event before every sched class event carrying the tid to tgid mapping.

Just plop a kprobe on top of __schedule()

-- Steve

> 
> 2) if everything fails, revert to use /proc/PID/stat, which however can be slow and racy if the process does not exist anymore when I read back the ftrace buffers.
> 
> Thanks & ciao,
> 
> Claudio


  reply	other threads:[~2019-03-14 18:20 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
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 [this message]
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=20190314142034.35469af8@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).