On Mon, Jan 29, 2018 at 2:27 PM, Ben Pfaff <b...@ovn.org> wrote: > On Mon, Jan 29, 2018 at 02:16:24PM -0800, William Tu wrote: >> On Thu, Jan 25, 2018 at 3:39 PM, Ben Pfaff <b...@ovn.org> 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 <b...@ovn.org> >> > --- >> >> 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?
We init the postpone_barrier to 2 + ovs_barrier_init(&postpone_barrier, 2); and every daemon calls ovsrcu_exit will call + ovs_barrier_block(&postpone_barrier); which increments the counter and the ovsrcu_postpone_thread also calls + ovs_barrier_block(&postpone_barrier); So if one more daemon calls ovsrcu_exit, then we have to bump the number to 3? William _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev