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 <[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? >
Yes, I am still working on it and should have a v4 soon. > -- Steve >
