Messages in this thread | | | Date | Tue, 7 Jun 2005 13:04:09 +0200 | From | Ingo Molnar <> | Subject | [patch] Real-Time Preemption, -RT-2.6.12-rc6-V0.7.47-20 |
| |
i have released the -V0.7.47-20 Real-Time Preemption patch, which can be downloaded from the usual place:
http://redhat.com/~mingo/realtime-preempt/
i've implemented two new features:
- new debugging feature: CONFIG_DEBUG_RT_LOCKING_MODE, which adds the /proc/sys/kernel/preempt_locks flag (default: 0). This way the 'locking model' can be switched runtime - very useful for debugging and profiling. Value 0 means that all spinlocks and rwlocks are implemented via raw spinlocks/rwlocks. (which disable preemption, increase latency, but improve throughput) Value 1 means the kernel will fully preempt all locks again. (NOTE: the only safe runtime switching of the locking model can be done while the system is idle, so i've implemented the flag via two flags where the idle thread propagates the new value from the user-flag to the kernel-flag. You should put a "sleep 1" into scripts that switch the locking mode, to guarantee that the new flag value is picked up.)
- performance feature: i've implemented a new scheduler feature called 'delayed preemption', which turns sync wakeups into guaranteed wakeups, while preserving their workload-batching properties. A delayed preemption request is implemented via the TIF_NEED_RESCHED_DELAYED flag, which runs in parallel to the "immediate preemption" TIF_NEED_RESCHED flag. If this works out fine then it will be a suitable replacement for the upstream sync-wakeups facility as well.
delayed preemption already improved the performance of 'hackbench' under PREEMPT_RT quite signifiantly.
to build a -V0.7.47-20 tree, the following patches have to be applied:
http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.tar.bz2 http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.12-rc6.bz2 http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.12-rc6-V0.7.47-20
Ingo - 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/
| |