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" [off-list ref] wrote:
quoted
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