mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Leonardo Brás" <leobras@redhat.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Yury Norov <yury.norov@gmail.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Nadav Amit <namit@vmware.com>,
	Zhen Lei <thunder.leizhen@huawei.com>,
	Chen Zhongjin <chenzhongjin@huawei.com>,
	linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [RFC PATCH 1/1] smp: Add tracepoints for functions called with smp_call_function*()
Date: Wed, 19 Apr 2023 01:04:21 -0300	[thread overview]
Message-ID: <637d8a822f130c63711169973a737273cffa5c3b.camel@redhat.com> (raw)
In-Reply-To: <20230406094947.6b92084c@gandalf.local.home>

On Thu, 2023-04-06 at 09:49 -0400, Steven Rostedt wrote:
> On Thu, 06 Apr 2023 05:42:13 -0300
> Leonardo Brás <leobras@redhat.com> wrote:
> 
> > Hello Sebastian, thanks for the heads up!
> > 
> > IIUC Valentin is adding/improving tracepoints that are collected in the
> > requesting CPU, at the moment of scheduling the IPI, which are also useful.
> > 
> > But on my scenario, would be nice to actually have the information on the time
> > window in which the requested function is running in the requested CPU. 
> > 

Hello Steven,

> 
> Well once you know the functions that are being called (running your test
> case with the IPI trace events), then you can get the timings of those same
> functions by:
> 
>  # cd /sys/kernel/tracing
>  # echo '<space-delimited-list-of-functions>' > set_ftrace_filter
>  # echo function_graph > current_tracer
> 
> Then the function graph will give you those timings.

IIUC, the use scenario of your suggestion would be something like:

1) Run something until we get a deadline miss in given CPU
2) Get the log -> Which functions were scheduled on that CPU in the last N time
3) Add those functions to the ftrace_filter
4) Run again until a deadline miss again

If that's correct, there are some points worth mentioning:
a) It requires getting the deadline miss again, which may take non-negligible
time for reproducing, slowing the debug process. The suggested change would get
the functions in the first run.
b) Where is no guarantee the next deadline time window will contain (only) those
functions. In case some are missing, we would need to add the new functions and
run the test once more.
c) Those functions could be called outside of remote scheduling context, and
would dirty our log.

> 
> -- Steve
> 

Thanks for reviewing and contributing, Steve!

Leo


  reply	other threads:[~2023-04-19  4:05 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-06  7:57 Leonardo Bras
2023-04-06  8:15 ` Sebastian Andrzej Siewior
2023-04-06  8:42   ` Leonardo Brás
2023-04-06 13:49     ` Steven Rostedt
2023-04-19  4:04       ` Leonardo Brás [this message]
2023-04-06  9:55 ` Peter Zijlstra
2023-04-19  3:45   ` Leonardo Brás
2023-05-03  4:23     ` Leonardo Brás
2023-05-03 14:59     ` Peter Zijlstra
2023-05-03 15:53       ` Leonardo Bras Soares Passos
2023-05-04 11:59       ` Valentin Schneider
2023-05-04 13:34         ` Steven Rostedt
2023-05-04 15:01         ` Peter Zijlstra
2023-05-10 20:27         ` Leonardo Brás
2023-05-10 22:18           ` Leonardo Bras Soares Passos
2023-05-10 23:05             ` Leonardo Bras Soares Passos
2023-05-11  8:13           ` Valentin Schneider
2023-05-11  9:25             ` Leonardo Bras Soares Passos

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=637d8a822f130c63711169973a737273cffa5c3b.camel@redhat.com \
    --to=leobras@redhat.com \
    --cc=bigeasy@linutronix.de \
    --cc=chenzhongjin@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=namit@vmware.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=thunder.leizhen@huawei.com \
    --cc=yury.norov@gmail.com \
    /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

all inboxes | Powered by JetHome®