On May 29, 2014, at 10:49 AM, Alex Wang <al...@nicira.com> wrote: > It is actually in a high level, > > udpif_revalidator() -> xpthread_barrier_wait() > >
If I read the code correctly, the barriers are used to synchronize the beginning and the end of the actual revalidation, which happens entirely in revalidate(), and can take easily 1000ms. My question is that will the fact that a thread is that long without quiescing problematic for ovs-rcu? Can the list of postponed operations grow very large? When we start using RCU for the classifier, we can have 100000 flows being postpone-freed during those 1000ms. It may also be that I read the code wrong, or that ovs-rcu would not need these threads to quiesce (?) Jarno > On Thu, May 29, 2014 at 10:46 AM, Jarno Rajahalme <jrajaha...@nicira.com> > wrote: > > On May 29, 2014, at 10:02 AM, Ben Pfaff <b...@nicira.com> wrote: > >> On Thu, May 29, 2014 at 09:59:44AM -0700, Jarno Rajahalme wrote: >>> >>> On May 29, 2014, at 9:52 AM, Ben Pfaff <b...@nicira.com> wrote: >>> >>>> On Wed, May 28, 2014 at 06:55:41PM -0700, Alex Wang wrote: >>>>> Since some threads do not call time_poll() regularly in their main loop >>>>> (e.g. non-leader revalidator threads), their intermittent invocation of >>>>> time_poll() in other modules can cause warnings like below: >>>>> >>>>> "Unreasonably long 16518ms poll interval". >>>>> >>>>> To suppress such warning, this commit allows thread to disable poll >>>>> interval >>>>> check in time_poll() by calling disable_check_poll_interval(). >>>>> >>>>> Signed-off-by: Alex Wang <al...@nicira.com> >>>> >>>> Is this just because of the xpthread_barrier_wait() calls? It might >>>> be nice to instead write our own poll_block()-able barriers. >>> >>> Also, is it possible that these long poll intervals could also >>> interplay with ovs-rcu? Do the revalidator threads ever quiesce, or >>> do they not need to? >> >> xpthread_barrier_wait() quiesces. > > I don’t see the revalidate() calling this? > > Jarno > >
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
