On Mon, Jan 29, 2018 at 2:44 PM, Ben Pfaff <[email protected]> wrote: > 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.
Oh, I see now. The postpone_barrier is only shared between the two. then there is no such issue. thank for clarifying. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
