Re: [PATCH v3 1/4] tracing/preemptirq: Optimize preempt_disable/enable() tracepoint overhead

[Wander Lairson Costa <wander@redhat.com>]

On Tue, Apr 28, 2026 at 02:51:51PM -0400, Steven Rostedt wrote:
> On Fri, 13 Mar 2026 12:36:10 -0300
> Wander Lairson Costa <wander@redhat.com> wrote:
> 
> > On Fri, Mar 13, 2026 at 10:04:04AM +0100, Peter Zijlstra wrote:
> > > On Thu, Mar 12, 2026 at 02:19:15PM -0300, Wander Lairson Costa wrote:
> > >   
> > > > > That's significant bloat, for really very little gain. Realistically
> > > > > nobody is going to need these.
> > > > >   
> > > > 
> > > > Of course, I can't speak for others, but more than once I debugged issues
> > > > that those tracepoints had made my life far easier. Those cases convinced
> > > > me that such a feature would be worth it. But if you don't see
> > > > value and will reject the patches no matter what, nothing can be done,
> > > > and I will have to accept defeat.  
> > > 
> > > If distros are going to enable this, I suppose I'm not going to stop
> > > this. But I do very much worry about the general bloat of things, there
> > > are a *LOT* of preempt_{dis,en}able() sites.
> > >   
> > 
> > We plan to enable these tracepoints in the RHEL kernel-rt to track
> > extended non-preemptible states that cause high latencies. These
> > issues occasionally surface in customer OpenShift deployments, where
> > deploying a custom debug kernel is highly impractical. Having these
> > tracepoints available in the distribution kernel would be handful for
> > debugging these production systems. That said, I expect enabling this
> > feature to be the exception rather than the rule — most distribution
> > kernels would leave it disabled.
> 
> Is this work going to continue? Or should I just change the status to
> "reject" in patchwork?
> 

Yes, I am still working on it and should have a v4 soon.

> -- Steve
>