Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

2016-09-29 Thread Thomas Gleixner
On Mon, 26 Sep 2016, Peter Zijlstra wrote: > On Mon, Sep 26, 2016 at 11:37:27AM -0400, Steven Rostedt wrote: > > On Mon, 26 Sep 2016 11:35:03 -0400 > > Steven Rostedt wrote: > > > > > Especially now that the code after the spin_unlock(>lock) is now a > > > critical section

Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

2016-09-29 Thread Thomas Gleixner
On Mon, 26 Sep 2016, Peter Zijlstra wrote: > On Mon, Sep 26, 2016 at 11:37:27AM -0400, Steven Rostedt wrote: > > On Mon, 26 Sep 2016 11:35:03 -0400 > > Steven Rostedt wrote: > > > > > Especially now that the code after the spin_unlock(>lock) is now a > > > critical section (preemption is

Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

2016-09-29 Thread Peter Zijlstra
On Thu, Sep 29, 2016 at 10:43:54AM -0400, Thomas Gleixner wrote: > On Mon, 26 Sep 2016, Peter Zijlstra wrote: > > > On Mon, Sep 26, 2016 at 11:37:27AM -0400, Steven Rostedt wrote: > > > On Mon, 26 Sep 2016 11:35:03 -0400 > > > Steven Rostedt wrote: > > > > > > > Especially

Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

2016-09-29 Thread Peter Zijlstra
On Thu, Sep 29, 2016 at 10:43:54AM -0400, Thomas Gleixner wrote: > On Mon, 26 Sep 2016, Peter Zijlstra wrote: > > > On Mon, Sep 26, 2016 at 11:37:27AM -0400, Steven Rostedt wrote: > > > On Mon, 26 Sep 2016 11:35:03 -0400 > > > Steven Rostedt wrote: > > > > > > > Especially now that the code

Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

2016-09-28 Thread Sebastian Andrzej Siewior
On 2016-09-26 14:32:14 [+0200], Peter Zijlstra wrote: > --- a/kernel/futex.c > +++ b/kernel/futex.c > @@ -1374,9 +1374,8 @@ static int wake_futex_pi(u32 __user *uad >* scheduled away before the wake up can take place. >*/ > spin_unlock(>lock); > - wake_up_q(_q); > -

Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

2016-09-28 Thread Sebastian Andrzej Siewior
On 2016-09-26 14:32:14 [+0200], Peter Zijlstra wrote: > --- a/kernel/futex.c > +++ b/kernel/futex.c > @@ -1374,9 +1374,8 @@ static int wake_futex_pi(u32 __user *uad >* scheduled away before the wake up can take place. >*/ > spin_unlock(>lock); > - wake_up_q(_q); > -

Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

2016-09-28 Thread Peter Zijlstra
On Wed, Sep 28, 2016 at 11:07:40AM +0200, Sebastian Andrzej Siewior wrote: > On 2016-09-26 14:32:14 [+0200], Peter Zijlstra wrote: > > --- a/kernel/futex.c > > +++ b/kernel/futex.c > > @@ -1374,9 +1374,8 @@ static int wake_futex_pi(u32 __user *uad > > * scheduled away before the wake up can

Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

2016-09-28 Thread Peter Zijlstra
On Wed, Sep 28, 2016 at 11:07:40AM +0200, Sebastian Andrzej Siewior wrote: > On 2016-09-26 14:32:14 [+0200], Peter Zijlstra wrote: > > --- a/kernel/futex.c > > +++ b/kernel/futex.c > > @@ -1374,9 +1374,8 @@ static int wake_futex_pi(u32 __user *uad > > * scheduled away before the wake up can

Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

2016-09-26 Thread Peter Zijlstra
On Mon, Sep 26, 2016 at 11:37:27AM -0400, Steven Rostedt wrote: > On Mon, 26 Sep 2016 11:35:03 -0400 > Steven Rostedt wrote: > > > Especially now that the code after the spin_unlock(>lock) is now a > > critical section (preemption is disable). There's nothing obvious in > >

Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

2016-09-26 Thread Peter Zijlstra
On Mon, Sep 26, 2016 at 11:37:27AM -0400, Steven Rostedt wrote: > On Mon, 26 Sep 2016 11:35:03 -0400 > Steven Rostedt wrote: > > > Especially now that the code after the spin_unlock(>lock) is now a > > critical section (preemption is disable). There's nothing obvious in > > futex.c that says it

Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

2016-09-26 Thread Peter Zijlstra
On Mon, Sep 26, 2016 at 11:35:03AM -0400, Steven Rostedt wrote: > On Mon, 26 Sep 2016 17:22:28 +0200 > Peter Zijlstra wrote: > > > > > + /* > > > > +* We should deboost before waking the top waiter task such that > > > > +* we don't run two tasks with

Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

2016-09-26 Thread Peter Zijlstra
On Mon, Sep 26, 2016 at 11:35:03AM -0400, Steven Rostedt wrote: > On Mon, 26 Sep 2016 17:22:28 +0200 > Peter Zijlstra wrote: > > > > > + /* > > > > +* We should deboost before waking the top waiter task such that > > > > +* we don't run two tasks with the 'same' priority.

Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

2016-09-26 Thread Steven Rostedt
On Mon, 26 Sep 2016 11:35:03 -0400 Steven Rostedt wrote: > Especially now that the code after the spin_unlock(>lock) is now a > critical section (preemption is disable). There's nothing obvious in > futex.c that says it is. Not to mention, this looks like it will break

Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

2016-09-26 Thread Steven Rostedt
On Mon, 26 Sep 2016 11:35:03 -0400 Steven Rostedt wrote: > Especially now that the code after the spin_unlock(>lock) is now a > critical section (preemption is disable). There's nothing obvious in > futex.c that says it is. Not to mention, this looks like it will break PREEMPT_RT as wake_up_q()

Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

2016-09-26 Thread Steven Rostedt
On Mon, 26 Sep 2016 17:22:28 +0200 Peter Zijlstra wrote: > > > + /* > > > + * We should deboost before waking the top waiter task such that > > > + * we don't run two tasks with the 'same' priority. This however > > > + * can lead to prio-inversion if we would get

Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

2016-09-26 Thread Steven Rostedt
On Mon, 26 Sep 2016 17:22:28 +0200 Peter Zijlstra wrote: > > > + /* > > > + * We should deboost before waking the top waiter task such that > > > + * we don't run two tasks with the 'same' priority. This however > > > + * can lead to prio-inversion if we would get preempted after > > > + *

Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

2016-09-26 Thread Peter Zijlstra
On Mon, Sep 26, 2016 at 11:15:11AM -0400, Steven Rostedt wrote: > On Mon, 26 Sep 2016 14:32:14 +0200 > Peter Zijlstra wrote: > > > > --- a/kernel/futex.c > > +++ b/kernel/futex.c > > @@ -1374,9 +1374,8 @@ static int wake_futex_pi(u32 __user *uad > > * scheduled away

Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

2016-09-26 Thread Peter Zijlstra
On Mon, Sep 26, 2016 at 11:15:11AM -0400, Steven Rostedt wrote: > On Mon, 26 Sep 2016 14:32:14 +0200 > Peter Zijlstra wrote: > > > > --- a/kernel/futex.c > > +++ b/kernel/futex.c > > @@ -1374,9 +1374,8 @@ static int wake_futex_pi(u32 __user *uad > > * scheduled away before the wake up can

Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

2016-09-26 Thread Steven Rostedt
On Mon, 26 Sep 2016 14:32:14 +0200 Peter Zijlstra wrote: > > --- a/kernel/futex.c > +++ b/kernel/futex.c > @@ -1374,9 +1374,8 @@ static int wake_futex_pi(u32 __user *uad >* scheduled away before the wake up can take place. >*/ > spin_unlock(>lock); > -

Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

2016-09-26 Thread Steven Rostedt
On Mon, 26 Sep 2016 14:32:14 +0200 Peter Zijlstra wrote: > > --- a/kernel/futex.c > +++ b/kernel/futex.c > @@ -1374,9 +1374,8 @@ static int wake_futex_pi(u32 __user *uad >* scheduled away before the wake up can take place. >*/ > spin_unlock(>lock); > - wake_up_q(_q); >

[PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

2016-09-26 Thread Peter Zijlstra
We should deboost before waking the high-priority task, such that we don't run two tasks with the same "state" (priority, deadline, sched_class, etc). In order to make sure the boosting task doesn't start running between unlock and deboost (due to 'spurious' wakeup), we move the deboost under the

[PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter

2016-09-26 Thread Peter Zijlstra
We should deboost before waking the high-priority task, such that we don't run two tasks with the same "state" (priority, deadline, sched_class, etc). In order to make sure the boosting task doesn't start running between unlock and deboost (due to 'spurious' wakeup), we move the deboost under the