[LTP] [PATCH v2] futex_cmp_requeue01: fix test expectations
Jan Stancek
jstancek@redhat.com
Fri Dec 6 00:19:10 CET 2019
Any thoughts about my last reply?
----- Original Message -----
>
>
> ----- Original Message -----
> > Hi!
> > > > Unless spurious wakeup has happened between the requeue and wake
> > > > operation which means that the num_requeues can be smaller because we
> > > > will wake up less than requeued processes. So if we sampled spurious
> > > > wakeups before the requeue operation and after the futex_wake() for
> > > > requeued processes and call it delta_spurious we would get a range:
> > > >
> > > > TST_RET - num_requeues >= set_wakes
> > >
> > > This doesn't look correct if we consider spurious wakeups:
> > >
> > > 5 processes, set_wakes = 5, set_requeue = 0, 1 spuriously wakes up,
> > > remaining 4 are woken up by futex(), 0 are requeued:
> > >
> > > 4 - 0 >= 5
> >
> > Well I was betting on the fact that we wake up much less processes than
> > we attempt to lock on the futex and that waking up processes takes
> > precedence. I we can add delta_spurious to the right side that wouldn't
> > change much and we end up being correct all the time, i.e.
> >
> > TST_RET + delta_spurious - num_requeues >= set_wakes
>
> I'd go with just spurious instead of delta_spurious. If there is spurious
> wake up before requeue (and first sample), wouldn't that fail in same way
> as example above?
>
> TST_RET + delta_spurious - num_requeues >= set_wakes
> 4 + 0 - 0 >= 5
>
> Also delta_spurious looks racy, because it's based on counter
> that is increased only after user-space gets chance to run. But process
> may have been already removed from futex queue on kernel side.
> So 'first sample before requeue' can see inaccurate state.
>
> So I'd tweak your check to:
> set_wakes-spurious <= TST_RET-num_requeues <= set_wakes+spurious
>
>
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp
>
>
More information about the ltp
mailing list