Re: [PATCH v2] rcu/kvfree: Add kvfree_rcu_barrier() API

[Paul E. McKenney]

On Wed, Sep 11, 2024 at 11:43:54AM +0200, Uladzislau Rezki wrote:
> On Tue, Sep 10, 2024 at 08:42:54AM -0700, Paul E. McKenney wrote:
> > On Tue, Aug 20, 2024 at 05:59:35PM +0200, Uladzislau Rezki (Sony) wrote:
> > > Add a kvfree_rcu_barrier() function. It waits until all
> > > in-flight pointers are freed over RCU machinery. It does
> > > not wait any GP completion and it is within its right to
> > > return immediately if there are no outstanding pointers.
> > > 
> > > This function is useful when there is a need to guarantee
> > > that a memory is fully freed before destroying memory caches.
> > > For example, during unloading a kernel module.
> > > 
> > > Signed-off-by: Uladzislau Rezki (Sony) <urezki@xxxxxxxxx>
> > > Signed-off-by: Vlastimil Babka <vbabka@xxxxxxx>
> > 
> > As a follow-on patch, once kvfree_rcu_barrier() is accepted into
> > mainline, should we add a call to kvfree_rcu_barrier() to the
> > rcu_barrier_throttled() function in kernel/rcu/tree.c?
> > 
> > This would allow the do_rcu_barrier module parameter to be used to clear
> > out kfree_rcu() as well as call_rcu() work.  This would be useful to
> > people running userspace benchmarks that cause the kernel to do a lot
> > of kfree_rcu() calls.  Always good to avoid messing up the results from
> > the current run due to deferred work from the previous run.  Even better
> > would be to actually account for the deferred work, but do_rcu_barrier
> > can help with that as well.  ;-)
> > 
> > Thoughts?
> >
> Makes sense. To be make sure that all objects are flushed. And as you
> mentioned it is good to have it for benchmarking as a return to a baseline
> point.
> 
> One issue is probably a "name" which would be common for both:
> 
> rcu_barrier()
> kvfree_rcu_barrier()
> 
> i mean /sys/module/rcutree/parameters/do_rcu_barrier. From how i
> would see it, it is supposed to trigger just rcu_barrier() API.

One approach would be to keep the old functionality, but create
a new sysfs variable that does both.  Except that to avoid code
duplication, we would likely end up with both actually doing
both.

Another approach is to rename the sysfs variable.  This might
work if there are not too many people using it.  Might.  ;-)

Other approaches?

						Thanx, Paul