On Mon, Aug 19, 2024 at 04:07:16PM GMT, Paul E. McKenney wrote: > On Mon, Aug 19, 2024 at 12:59:26PM -0400, Kent Overstreet wrote: > > New data structure for tracking objects waiting on an RCU grace period. > > Supports regular RCU and SRCU, and possibly other RCU flavors in the > > future. Uses radix trees for tracking pending objects, falling back to > > linked lists on allocation failure. > > > > This gets us a more general replacement for SLAB_TYPESAFE_BY_RCU, and a > > cleaner and slightly faster backend for kvfree_call_rcu(), and > > in the future a faster backend for call_rcu() as well. > > > > There's still some small todo items, mentioned in the relevant patches. > > > > Paul - I'm considering putting this into 6.11 for bcachefs (not the > > patch that switches kvfree_rcu, of course), as I need it rather > > pressingly. Thoughts? I can put it in fs/bcachefs/ if you hate it :) > > I am having a hard time imagining it being ready for inclusion in > kernel/rcu by the upcoming (v6.12) merge window, so if you need it then, > you will need to pull it into fs/bcachefs. > > Don't get me wrong, it has improved since the June version. And we > can always move it later, if/when appropriate. > > And yes, the kvfree_rcu() changes would need some serious performance > evaluation by the people who benefitted from the changes that make > kvfree_rcu() what it is today. So let's please defer that one. > > Having the equivalent of SLAB_TYPESAFE_BY_SRCU could be attractive, > but I suspect that there are smaller changes that get us that with the > existing slab allocator. I seriously doubt that - where are you going to stash the srcu_struct pointer? This is small and self contained, which is a _major_ win vs. dumping more complex algorithmic stuff into slub.
