On Fri, 13 Mar 2026 12:36:10 -0300
Wander Lairson Costa <[email protected]> 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?
-- Steve
