Re: [PATCH] bcachefs: pending_rcu_items

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 17, 2024 at 10:24:54PM -0400, Kent Overstreet wrote:
> On Mon, Jun 17, 2024 at 05:15:29PM -0700, Paul E. McKenney wrote:
> > If it ever becomes helpful to make this work for any of the RCU Tasks
> > flavors, the rcutorture_type enum from kernel/rcu/rcu.h might be of help.
> > Until then, NULL works just fine.
> 
> Certainly
> 
> > > - Tracks pending items in a radix tree; falls back to linked list if
> > >   radix tree allocation fails
> > 
> > I am still having trouble seeing what a radix tree brings to the table
> > in this case, but again, migtht as well dig in.
> 
> It's simpler, and (marginally) more efficient than list-of-pages.
> 
> My new implementation of kvfree_call_rcu() on top of this data structure
> is now looking faster than the existing version - and I'm using smaller
> nodes (512 bytes instead of full pages).

OK.  We will need to look carefully at the performance comparisons.
Lots of places for overhead to hide in both schemes.  ;-)

> > > +static inline unsigned long __start_poll_synchronize_rcu(struct srcu_struct *ssp)
> > > +{
> > > +	return ssp
> > > +		? start_poll_synchronize_srcu(ssp)
> > > +		: start_poll_synchronize_rcu();
> > > +}
> > 
> > I don't get why you 
> > 
> > > +static inline void __rcu_barrier(struct srcu_struct *ssp)
> > > +{
> > > +	return ssp
> > > +		? srcu_barrier(ssp)
> > > +		: rcu_barrier();
> > > +}
> > 
> > You will likely need something like these:
> > 
> > static inline void __get_completed_synchronize_rcu(struct srcu_struct *ssp)
> > {
> > 	return ssp
> > 		? get_completed_synchronize_srcu(ssp)
> > 		: get_completed_synchronize_rcu();
> > }
> > 
> > static inline void __same_state_synchronize_rcu(struct srcu_struct *ssp)
> > {
> > 	return ssp
> > 		? same_state_synchronize_srcu(ssp)
> > 		: same_state_synchronize_rcu();
> > }
> > 
> > The point of these is to get around the earlier issue where three cookies
> > appeared to be valid due to time delays.  But perhaps you found some
> > other way around that.
> 
> Yes, that comes from a race between poll_state_synchronize() and
> start_poll_synchronize(), easily handled with a loop.

Plus call_srcu() can also get its oar in.  But more later.

> To be honest, I'm still not getting your intended use of the other
> helpers; to be honest, just comparing sequence numbers with
> ULONG_CMP_GE/LT seems simplest to my brain.


[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux