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. Thanx, Paul
