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 [email protected]
"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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
