lkml.org 
[lkml]   [2017]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: a competition when some threads acquire futex
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.

\
 
 \ /
  Last update: 2017-09-06 10:57    [W:0.110 / U:0.764 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site