Messages in this thread | | | Date | Sat, 01 Apr 2006 11:19:10 +1100 | From | Peter Williams <> | Subject | Re: [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/
| |