[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <637d8a822f130c63711169973a737273cffa5c3b.camel@redhat.com>
Date: Wed, 19 Apr 2023 01:04:21 -0300
From: Leonardo Brás <leobras@...hat.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Masami Hiramatsu <mhiramat@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Yury Norov <yury.norov@...il.com>,
"Paul E. McKenney" <paulmck@...nel.org>,
"Peter Zijlstra (Intel)" <peterz@...radead.org>,
Nadav Amit <namit@...are.com>,
Zhen Lei <thunder.leizhen@...wei.com>,
Chen Zhongjin <chenzhongjin@...wei.com>,
linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
Marcelo Tosatti <mtosatti@...hat.com>
Subject: Re: [RFC PATCH 1/1] smp: Add tracepoints for functions called with
smp_call_function*()
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@...hat.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
Powered by blists - more mailing lists