It is actually in a high level, udpif_revalidator() -> xpthread_barrier_wait()
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
