All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre Peiffer <pierre.peiffer@bull.net>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>, Ulrich Drepper <drepper@redhat.com>,
	Jakub Jelinek <jakub@redhat.com>,
	Jean-Pierre Dion <jean-pierre.dion@bull.net>
Subject: [PATCH 2.6.20-rc5 0/4] futexes functionalities and improvements
Date: Wed, 17 Jan 2007 09:59:23 +0100	[thread overview]
Message-ID: <45ADE56B.4010608@bull.net> (raw)

Hi,

	Today, there are several functionalities or improvements about futexes included
in -rt kernel tree, which, I think, it make sense to have in mainline.

Among them, there are:
     * futex use prio list : allows RT-threads to be woken in priority order
instead of FIFO order.
     * futex_wait use hrtimer : allows the use of finer timer resolution.
     * futex_requeue_pi functionality : allows use of requeue optimization for
PI-mutexes/PI-futexes.
     * futex64 syscall : allows use of 64-bit futexes instead of 32-bit.

The following mails provide the corresponding patches.


I re-send this series for kernel 2.6.20-rc5 with this small modifications:

  - futex_use_prio_list patch stores now all non-real-time threads with the same
priority (MAX_RT_PRIO, which is a lower priority than real-time priorities),
causing them to be stored in FIFO order. RT-threads are still woken first in
priority order.
  - futex_requeue_pi: I've found (and corrected of course) a bug causing a
memory leak.

plist (patch 1/4) is still under discussion: I think it should be taken into
account, because it concerns a correctness issue with a very low cost as
drawback (I would even say "without noticeable cost" ;-) but that's my opinion
of course).
Anyway, I still can provide the same series without patch 1/4 if needed.

Comments and feedback are still welcome, as usual.

-- 
Pierre


                 reply	other threads:[~2007-01-17  9:00 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=45ADE56B.4010608@bull.net \
    --to=pierre.peiffer@bull.net \
    --cc=drepper@redhat.com \
    --cc=jakub@redhat.com \
    --cc=jean-pierre.dion@bull.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.