On Fri, Jun 19, 2020 at 05:46:52PM +0200, Uladzislau Rezki wrote: > On Thu, Jun 18, 2020 at 02:34:27PM -0700, Paul E. McKenney wrote: > > On Thu, Jun 18, 2020 at 11:17:09PM +0200, Uladzislau Rezki wrote: > > > > > <snip> > > > > > trace_rcu_invoke_kfree_bulk_callback( > > > > > rcu_state.name, bkvhead[i]->nr_records, > > > > > bkvhead[i]->records); > > > > > if (i == 0) > > > > > kfree_bulk(bkvhead[i]->nr_records, > > > > > bkvhead[i]->records); > > > > > else > > > > > vfree_bulk(bkvhead[i]->nr_records, > > > > > bkvhead[i]->records); > > > > > <snip> > > > > > > > > > > Matthew, what is your thought? > > > > > > > > That was my thinking too. If we had a kvfree_bulk(), I would expect it to > > > > handle a mixture of vfree and kfree, but you've segregated them already. > > > > So I think this is better. > > > > > > > Yes, the segregation is done. Having vfree_bulk() is enough then. > > > We are on the same page :) > > > > Very good. When does kfree_rcu() and friends move out of kernel/rcu? > > > Do you mean to move the whole logic of kfree_rcu() from top to down to mm/? I do mean exactly that. That was my goal some years back when Rao Shoaib was making the first attempt along these lines, and it remains my goal. After all, if this effort is at all successful, the coupling between kfree_rcu() with slab/slob/slub will become much tighter than that between kfree_rcu() and RCU. There will need to be some additional RCU APIs used by kfree_rcu(), for example, something to tell RCU how many blocks are awaiting a grace period. But these are narrow and easily defined APIs. Thanx, Paul
