[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>
wrote:

> 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
revalidator
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
seq_change,




> 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
example?

Thanks,
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