[ovs-dev] [PATCH V3 1/2] ofproto-dpif-upcall: Allow main thread to pause all revalidators.

Alex Wang alexw at nicira.com
Sat Aug 29 22:24:30 UTC 2015

On Sat, Aug 29, 2015 at 11:34 AM, Joe Stringer <joestringer at nicira.com>

> Thanks for working on this, Alex. I've considered implementing an
> approach like this before, but haven't had a strong reason to.
> On 29 August 2015 at 00:42, Alex Wang <ee07b291 at gmail.com> wrote:
> > This commit adds logic using ovs barrier to allow main thread pause
> > all revalidators.  This new feature will be used in a later patch.
> >
> > Signed-off-by: Alex Wang <ee07b291 at gmail.com>
> <snip>
> > @@ -762,6 +791,11 @@ udpif_revalidator(void *arg)
> >
> >      revalidator->id = ovsthread_id_self();
> >      for (;;) {
> > +        /* Pauses all revalidators if wanted. */
> > +        if (latch_is_set(&udpif->pause_latch)) {
> > +            revalidator_pause(revalidator);
> > +        }
> > +
> Is there anything that ensures all revalidators are either before this
> statement, or after this statement, when the latch is modified?

I think this should not matter, since the latch_wait() will cause
waking up immediately...  And latch has only two states (set or not), unlike
the sequence number, so we do not need to worry about missing the

> We've
> had issues with barriers before where not all revalidators hit a
> barrier, and that can cause deadlocks or hung threads in some cases.
> For instance, what happens if the system is under heavy load (let's
> say, nested virtualization) and we have one revalidator thread which
> runs and proceeds through this piece, then a second revalidator is
> delayed before executing this, then the latch is modified by the main
> thread, then the second revalidator gets scheduled to run? There won't
> be enough threads hitting the barrier to let it continue.

In that case, the latch_wait() should cause thread waking up immediately.

If I'm not addressing your concern, could you provide a more specific

Alex Wang,

> I think that this type of issue doesn't affect exit_latch, because
> exit_latch is only checked by the lead revalidator thread, which then
> raises udpif->reval_exit before the barrier, and the value of
> udpif->reval_exit is checked by all revalidators after the barrier.
> Perhaps it would make sense in this case to follow that logic too?
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev

More information about the dev mailing list