Re: [patch] PI-futex patchset: -V4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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]
  Powered by Linux