On Mon, Jan 29, 2018 at 02:16:24PM -0800, William Tu wrote: > On Thu, Jan 25, 2018 at 3:39 PM, Ben Pfaff <[email protected]> wrote: > > ovs-vswitchd makes extensive use of RCU to defer freeing memory past the > > latest time that it could be in use by a thread. Until now, ovs-vswitchd > > has not waited for RCU callbacks to fire before exiting. This meant that > > in many cases, when ovs-vswitchd exits, many blocks of memory are stuck in > > RCU callback queues, which valgrind often reports as "possible" memory > > leaks. > > > > This commit adds a new function ovsrcu_exit() that waits and fires as many > > RCU callbacks as it reasonably can. It can only do so for the thread that > > calls it and the thread that calls the callbacks, but generally speaking > > ovs-vswitchd shuts down other threads before it exits anyway, so this is > > pretty good. > > > > In my testing this eliminates most valgrind warnings for tests that run > > ovs-vswitchd. This ought to make it easier to distinguish new leaks that > > are real from existing non-leaks. > > > > Signed-off-by: Ben Pfaff <[email protected]> > > --- > > Looks good to me. > One limitation is that since this patch init the ovs barrier for size=2, > the ovsrcu_exit() can only be used in ovs-vswitchd. Otherwise users > have to remember to bump up this barrier number.
I don't understand that comment. Can you explain? Why would other daemons need a larger barrier number? _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
