[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <xhsmhh6voqqvw.mognet@vschneid.remote.csb>
Date: Tue, 14 Feb 2023 14:10:43 +0000
From: Valentin Schneider <vschneid@...hat.com>
To: linux-alpha@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-snps-arc@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-csky@...r.kernel.org,
linux-hexagon@...r.kernel.org, linux-ia64@...r.kernel.org,
loongarch@...ts.linux.dev, linux-mips@...r.kernel.org,
openrisc@...ts.librecores.org, linux-parisc@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, linux-riscv@...ts.infradead.org,
linux-s390@...r.kernel.org, linux-sh@...r.kernel.org,
sparclinux@...r.kernel.org, linux-xtensa@...ux-xtensa.org,
x86@...nel.org
Cc: "Paul E. McKenney" <paulmck@...nel.org>,
Steven Rostedt <rostedt@...dmis.org>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Juri Lelli <juri.lelli@...hat.com>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Marcelo Tosatti <mtosatti@...hat.com>,
Frederic Weisbecker <frederic@...nel.org>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>, Marc Zyngier <maz@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Russell King <linux@...linux.org.uk>,
Nicholas Piggin <npiggin@...il.com>,
Guo Ren <guoren@...nel.org>,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH v4 0/7] Generic IPI sending tracepoint
Hey folks,
On 19/01/23 14:36, Valentin Schneider wrote:
> Patches
> =======
>
> o Patches 1-5 spread out the tracepoint across relevant sites.
> Patch 5 ends up sprinkling lots of #include <trace/events/ipi.h> which I'm not
> the biggest fan of, but is the least horrible solution I've been able to come
> up with so far.
>
> o Patch 7 is trying to be smart about tracing the callback associated with the
> IPI.
>
> This results in having IPI trace events for:
>
> o smp_call_function*()
> o smp_send_reschedule()
> o irq_work_queue*()
> o standalone uses of __smp_call_single_queue()
>
This still rebases cleanly on top of the latest tip/sched/core, any
objections to parking it there?
Powered by blists - more mailing lists