Re: rcu pending

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

 



On Mon, Aug 19, 2024 at 12:16:42AM -0400, Kent Overstreet wrote:
> On Sun, Aug 18, 2024 at 08:52:59PM GMT, Paul E. McKenney wrote:
> > On Sun, Aug 18, 2024 at 09:19:16PM -0400, Kent Overstreet wrote:
> > > On Sun, Aug 18, 2024 at 10:01:42AM GMT, Paul E. McKenney wrote:
> > > > But you only need one callback per live outstanding "cookie" returned
> > > > from get_state_synchronize_rcu*() or start_poll_synchronize_rcu().
> > > > Or am I missing something here?
> > > 
> > > Maybe I am?
> > > 
> > > I've been assuming that if rcu callbacks are getting punted off to a
> > > kthread that we can't rely on them being completed in any particular
> > > timeframe - i.e. the number of grace periods with outstanding callbacks
> > > would be unbounded.
> > 
> > Exactly, and that is why there is a check for expired cookies during the
> > addition of a new data element that needs to wait for a grace period.
> > The only purpose of that call_rcu() callback is to act as a fallback in
> > case there is a long period of time with no newly arriving data elements
> > that need to wait for a grace period.
> > 
> > > You're saying that NUM_ACTIVE_RCU_POLL_FULL_OLDSTATE _does_ include
> > > grace periods with outstanding callbacks? Just want to be clear on that.
> > 
> > No, it does not, but given the algorithm outlined in my previous
> > email, it doesn't need to.  The point of the callbacks is *not* to
> > unconditionally drive things forward, but instead to provide a fallback
> > to do the necessary processing in the case nothing new arrives for an
> > extended period of time.
> 
> You can't use a fixed number of callback heads if there's going to be an
> unbounded number of callback heads outstanding.

The number of rcu_head structures is your choice, based on your choice
of data structure.  You can for example link together data elements that
have the same value of get_state_synchronize_rcu() cookie, and use a
single rcu_head structure for that group.  You could then do whatever
you want for the linking.

But even if you do choose to have a large number of rcu_head structures,
perhaps one per data element, there is no law saying that each and every
one of them needs to be passed to call_rcu().  For example, kfree_rcu()
requires an rcu_head structure in the objects passed to it, but in the
common (non-OOM) case, those structures go unused in favor of pages
of pointers.

So what were you really trying to get across to me here?

							Thanx, Paul




[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