On Thu, Jul 17, 2025 at 12:10:10PM -0400, Steven Rostedt wrote: > On Thu, 17 Jul 2025 08:48:40 -0700 > "Paul E. McKenney" <paulmck@xxxxxxxxxx> wrote: > > > So if there is some reason that you absolutely cannot immediately convert > > to SRCU-fast, let's please discuss. > > There's two reasons I wouldn't add it immediately. > > One, is the guard(srcu_fast) isn't in mainline yet. I would either need > to open code it, or play the tricks of basing code off your tree. Fair point! But guard(srcu_fast) isn't in my tree, either, just guard(srcu_fast_nopreempt). So why not add guard(srcu_fast) in your tree, and we can ack it. Yes, that means we will have a merge conflict at some point, but it will be a trivial one. > Two, I'm still grasping at the concept of srcu_fast (and srcu_lite for > that matter), where I rather be slow and safe than optimize and be > unsafe. The code where this is used may be faulting in user space > memory, so it doesn't need the micro-optimizations now. Straight-up SRCU and guard(srcu), then? Both are already in mainline. Or are those read-side smp_mb() calls a no-go for this code? Thanx, Paul
