Re: a competition when some threads acquire futex

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Sep 06, 2017 at 10:36:29AM +0200, Thomas Gleixner wrote:
> On Wed, 6 Sep 2017, chengjian (D) wrote:
> 
> > > > diff --git a/kernel/futex.c b/kernel/futex.c
> > > > index 3d38eaf..0b2d17a 100644
> > > > --- a/kernel/futex.c
> > > > +++ b/kernel/futex.c
> > > > @@ -1545,6 +1545,7 @@ static int wake_futex_pi(u32 __user *uaddr, u32
> > > > uval,
> > > > struct futex_pi_state *pi_
> > > >    	spin_unlock(&hb->lock);
> > > >   	wake_up_q(&wake_q);
> > > > +        _cond_resched( );
> > > 
> 
> > I wrote _cond_resched( ) in futex_wake( ) which will be called to wake up
> > waiters
> > when the process release the futex.
> > 
> > 
> > But the patch producted by git format-patch displayed in wake_futex_pi( ).
> 
> Ok. Still that patch has issues.
> 
> 1) It's white space damaged. Please use TAB not spaces for
>    indentation. checkpatch.pl would have told you.
> 
> 2) Why are you using _cond_resched() instead of plain cond_resched().
> 
>    cond_resched() is what you want to use.

Right, but even if it was a coherent patch, I'm not sure it makes sense.

futex_wait() / futex_wake() don't make ordering guarantees and in
general you don't get to have wakeup preemption if you don't run a
PREEMPT kernel.

So what makes this wakeup so special? Any changelog would need to have a
convincing argument.