On Mon, Aug 19, 2024 at 04:10:23PM GMT, Paul E. McKenney wrote: > On Mon, Aug 19, 2024 at 01:09:09PM -0400, Kent Overstreet wrote: > > On Mon, Aug 19, 2024 at 08:49:26AM GMT, Paul E. McKenney wrote: > > > On Mon, Aug 19, 2024 at 11:14:02AM -0400, Kent Overstreet wrote: > > > By "number of outstanding grace period sequence numbers" you mean > > > the number of outstanding grace period sequence numbers that have > > > memory blocks that have not yet been processed? If so, how could that > > > possibly matter more than the total number of memory blocks that have > > > not been processed, regardless of which grace-period number they are > > > associated with? Why would a huge number of memory blocks fail to > > > cause an OOM simply because they happen to be associated with a single > > > grace-period number? Or, to put it another way, suppose that same number > > > of memory blocks were distributed over a large number of grace-period > > > sequence numbers? How could this possibly cause an OOM to be more likely > > > than if the same nubmer of memory blocks were associated with a single > > > grace-period number? > > > > We just want a callback every time one of those grace periods expire, so > > the pending objects can be freed as soon as they're ready. > > > > This isn't _fatal_ for the kvfree_rcu() backend, since we have memory > > reclaim to fall back on, but it would still definitely be preferable for > > rcu_pending to be getting the notification from core RCU and avoid the > > more expensive memory reclaim path. > > > > It is more critical if we want to use this for a faster call_rcu() > > backend. > > I am still missing why the call to process_finished_items() from > __rcu_pending_enqueue() cannot cover this. Given the way that RCU works, > that has the potential to notify you *before* RCU's grace-period kthread > would get around to doing so. Not with any kind of bounds, since there's no predicting if that enqueue() call will happen, and not all potential users can process pending objects in enqueue(). Like I said, this isn't the most critical issue, I'm mainly thinking about if we want to use this to get rid of linked list overhead for call_rcu() processing itself.
