On Sat, Aug 29, 2015 at 11:34 AM, Joe Stringer <joestrin...@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 <ee07b...@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 <ee07b...@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@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
