public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Esben Nielsen <nielsen.esben@googlemail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [patch 3/3] [-rt] Fixes the timeout-bug in the rtmutex/PI-futex.
Date: Sun, 23 Jul 2006 10:57:41 -0400	[thread overview]
Message-ID: <1153666661.4002.4.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0607230217390.11861@localhost.localdomain>

On Sun, 2006-07-23 at 02:18 +0100, Esben Nielsen wrote:
> This patch fixes
> 
> 1) The timeout bug in rtmutexes and PI futexes: When a task is blocked on a 
> lock with timeout and times out it will not wakeup until the owner of the lock
> is done. This is because the owner is boosted to the same priority as the 
> blocked task and therefore has the CPU such the blocked task never gets around 
> to de-boost it!
> 
> 2) setscheduler() now does the PI walking - but defers the work to the blocked
> task.
> 
> 3) In general it makes sure that a task, which is boosting another has enough
> priority to do the de-boosting no matter how complicated the lock structure is, 
> or how many times the priorities have changed.
> 
> The idea behind the patch is simple:
> If a task is boosting another it is scheduled in LIFO order and it will never
> loose it's priority. This property lasts until it has left the lock operation
> (successfully or not).
> 
> The needed priority to do the unboosting is stored in task->boosting_prio.
> In the current patch this is always increasing (numerically decreasing) while
> trying to take a lock. In a future it might be found safe to decrease
> boosting_prio before finally leaving the lock operation.
> 
>   include/linux/rtmutex.h                               |    1
>   include/linux/sched.h                                 |    7
>   kernel/fork.c                                         |    1
>   kernel/rtmutex.c                                      |  151 +++++++++++++-----

It is possible that these changes can break the pi code in rtmutex.c.  I
haven't analyzed it enough yet.  But just so that you know that your
changes don't break the code, and to make it easier for me to look at
it. Please update Documentation/rt-mutex-design.txt including your
changes.  This will be a good exercise to see if it doesn't really break
anything, and it will give other reviewers a better starting point for
review.

>   kernel/rtmutex_common.h                               |    1
>   kernel/sched.c                                        |   14 +
>   scripts/rt-tester/t5-l4-pi-boost-deboost-setsched.tst |   42 +++--
>   scripts/rt-tester/t5-l4-pi-boost-deboost.tst          |   12 -
>   8 files changed, 167 insertions(+), 62 deletions(-)

-- Steve



  reply	other threads:[~2006-07-23 14:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20060723005210.973833000@localhost>
2006-07-23  1:18 ` [patch 1/3] [-rt] Fixes the timeout-bug in the rtmutex/PI-futex Esben Nielsen
2006-07-23  1:18 ` [patch 2/3] " Esben Nielsen
2006-07-23  1:18 ` [patch 3/3] " Esben Nielsen
2006-07-23 14:57   ` Steven Rostedt [this message]
2006-07-23 16:58     ` Esben Nielsen
2006-07-23 16:05       ` Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1153666661.4002.4.camel@localhost.localdomain \
    --to=rostedt@goodmis.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nielsen.esben@googlemail.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox