lkml.org 
[lkml]   [2006]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] PI-futex patchset: -V4
Ingo Molnar wrote:
> this is version -V4 of the PI-futex patchset (ontop of current -mm2,
> which includes -V3.)
>
> A clean queue of split-up patches can be found at:
>
> http://redhat.com/~mingo/PI-futex-patches/PI-futex-patches-V4.tar.gz
>
> the -V4 codebase has been tested on the glibc code (all testcases pass)
> and under load as well. (The -V4 code is included in the 2.6.16-rt12
> code as well that i released earlier today.)
>
> Changes since -V3:
>
> - added Esben Nielsen's PI locking code, Thomas Gleixner made it
> work in cornercases and under load. This is significantly simpler (it
> removes 50 lines of code from rtmutex.c). The main difference is that
> instead of holding all locks along a dependency chain, this code
> propagates PI priorities (and detects deadlocks) by holding at most
> two locks at once, and by being preemptible between such steps.
>
> - Jakub Jelinek did a detailed review of the new futex code and found
> some new races, which Thomas Gleixner fixed.
>
> - to fix a pthread_mutex_trylock() related race, FUTEX_TRYLOCK_PI has
> been added (Thomas Gleixner)
>
> - documentation fixes based on feedback from Tim Bird
>
> - added Documentation/pi-futex.txt (in addition to rt-mutex.txt)
>
> - added the plist debugging patch (which was part of -rt but wasnt part
> of the pi-futex queue before). This caught a couple of SMP bugs in
> the past.
>
> - implemented more scalable held-locks debugging - it's now a per-task
> list of held locks, instead of a global list. This is similarly
> effective to the global list, but much more scalable. (This approach
> will also be added to the stock kernel/mutex.c code.)
>
> - do not fiddle with irq flags in rtmutex.c - it's not needed.
>
> - clone/fork fix: do not let parent's potential PI priority 'leak' into
> child threads or processes.
>
> - added /proc/sys/kernel/max_lock_depth with a default limit of 1024,
> to limit the amount of deadlock-checking the kernel will do.
>
> - small enhancement to the t3-l1-pi-signal.tst testcase.

Wouldn't this be a good opportunity to redefine SCHED_BATCH as 4 instead
of 3 so that you can use ((p->policy & (SCHED_FIFO|SCHED_RR)) == 0)
instead of (p->policy != SCHED_NORMAL && p->policy != SCHED_BATCH)?
That expression will be called fairly frequently and SCHED_BATCH hasn't
been around long enough for a change of value to break very much use
space code.

Peter
--
Peter Williams pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-04-01 02:21    [W:0.076 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site