[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230504150113.GB1744142@hirez.programming.kicks-ass.net>
Date: Thu, 4 May 2023 17:01:13 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Valentin Schneider <vschneid@...hat.com>
Cc: Leonardo BrĂ¡s <leobras@...hat.com>,
Steven Rostedt <rostedt@...dmis.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Yury Norov <yury.norov@...il.com>,
"Paul E. McKenney" <paulmck@...nel.org>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
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>,
Daniel Bristot de Oliveira <bristot@...nel.org>
Subject: Re: [RFC PATCH 1/1] smp: Add tracepoints for functions called with
smp_call_function*()
On Thu, May 04, 2023 at 12:59:41PM +0100, Valentin Schneider wrote:
> With that said, I suppose this could still be helpful for e.g. osnoise to
> hook into and point the finger at which CPU/context sent the problematic
> IPI. Or more generally, as Leonardo suggested, to measure CSD IPI delivery
> times.
>
> One thing though is that trace_ipi_send_cpu*() is not used solely for
> CSD's, cf. irq_work_raise() or smp_send_reschedule(). We might want to
> split that into e.g. trace_csd_queue_cpu*() + trace_ipi_send*().
>
> Something like so...
>
Yeah, looks about right I suppose.. it generates more events, but given
we need the csd that's inevitable.
Powered by blists - more mailing lists