Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 20 May 2020 15:51:56 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Wojciech Kudla <wk.kernel@gmail.com>
Cc:     linux-kernel@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
        Nadav Amit <namit@vmware.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] smp: generic ipi_raise tracepoint
Message-ID: <20200520135156.GO317569@hirez.programming.kicks-ass.net>
References: <02b57f31-fc0c-df35-57bf-e0a297a7e6c4@gmail.com>
 <20200520133350.GN317569@hirez.programming.kicks-ass.net>
 <a9fbbf7d-28cd-2119-8519-2f1cd045acda@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a9fbbf7d-28cd-2119-8519-2f1cd045acda@gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, May 20, 2020 at 02:42:10PM +0100, Wojciech Kudla wrote:
> On 20/05/2020 14:33, Peter Zijlstra wrote:
> > We have bright shiny links like: https://lkml.kernel.org/r/$MSG-ID for
> > that. they allow me to go find the email in my local archive without
> > having to use a browser.
> 
> Apologies, beginner's mistake.
> 
> >> +static const char *ipi_reason_missing __tracepoint_string = "";
> > 
> > That is a pretty crap reason ;-)
> > 
> 
> I knew this was a long shot. There is no obvious way to 
> get/infer ipi reason in generic smp code at the moment.
> Any suggestions what we can put here in the meantime?
> Would "none" be more appropriate?

Depends a bit on what you actually want to achieve here.

For actual proper debugging this stuff I think I'd find it more useful
to have tracepoints one level up. So instead of tracing the IPIs, trace
the actual remote function call requests.

And in that case, trace the mask and the symbol name from csd->func.

And if you have that, who cares about the actual IPIs.