On Mon, Jan 29, 2018 at 02:35:35PM -0800, William Tu wrote: > On Mon, Jan 29, 2018 at 2:27 PM, Ben Pfaff <[email protected]> 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 <[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? > > 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?
How would daemons share a barrier? Our daemons don't use shared memory. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
