patches-3.6.4-rt11.tar.xz
md5sum:
20cdd858d8e22ed22117e6fbad756445 patches-3.6.4-rt11.tar.xz
Announce:
--------------
Dear RT Folks,
I'm pleased to announce the 3.6.4-rt11 release.
Changes since 3.6.3-rt10:
* Crypto wreckage fix (Milan Broz)
Another proof why copy and paste should be forbidden, but if that
would happen most of us would be serving time.
* Another attempt to tame SLUB
My previous approach turned out to be too naive though this one
has at least held up against massive memory stress tests. It's a
very simple and straight forward aproach now and while I'm quite
sure that it will not fall over as it did before, there might be
hidden latency issues with that new version.
So please give it a proper testing!
* Lazy preemption
It has become an obsession to mitigate the determinism
vs. throughput loss of RT. Looking at the mainline semantics of
preemption points gives a hint why RT sucks throughput wise for
ordinary SCHED_OTHER tasks. One major issue is the wakeup of
tasks which are right away preempting the waking task while the
waking task holds a lock on which the woken task will block right
after having preempted the wakee. In mainline this is prevented
due to the implicit preemption disable of spin/rw_lock held
regions. On RT this is not possible due to the fully preemptible
nature of sleeping spinlocks.
Though for a SCHED_OTHER task preempting another SCHED_OTHER task
this is really not a correctness issue. RT folks are concerned
about SCHED_FIFO/RR tasks preemption and not about the purely
fairness driven SCHED_OTHER preemption latencies.
So I introduced a lazy preemption mechanism which only applies to
SCHED_OTHER tasks preempting another SCHED_OTHER task. Aside of
the existing preempt_count each tasks sports now a
preempt_lazy_count which is manipulated on lock acquiry and
release. This is slightly incorrect as for lazyness reasons I
coupled this on migrate_disable/enable so some other mechanisms
get the same treatment (e.g. get_cpu_light).
Now on the scheduler side instead of setting NEED_RESCHED this
sets NEED_RESCHED_LAZY in case of a SCHED_OTHER/SCHED_OTHER
preemption and therefor allows to exit the waking task the lock
held region before the woken task preempts. That also works
better for cross CPU wakeups as the other side can stay in the
adaptive spinning loop.
For RT class preemption there is no change. This simply sets
NEED_RESCHED and forgoes the lazy preemption counter.
Initial test do not expose any observable latency increasement,
but history shows that I've been proven wrong before :)
The lazy preemption mode is per default on, but with
CONFIG_SCHED_DEBUG enabled it can be disabled via:
# echo NO_PREEMPT_LAZY >/sys/kernel/debug/sched_features
and reenabled via
# echo PREEMPT_LAZY >/sys/kernel/debug/sched_features
The test results so far are very machine and workload dependent,
but there is a clear trend that it enhances the non RT workload
performance.
Please give it a try and share your experience!
Known issues:
There is still some "softirq pending xx" fallout which I have
not been able to investigate yet, but that's on my top priority
list. It's not a critical issue and only annoys people with
CONFIG_NO_HZ=y configurations.
The delta patch against 3.6.4-rt10 is appended below and can be found
here:
http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/incr/patch-3.6.4-rt10-rt11.patch.xz
The RT patch against 3.6.4 can be found here:
http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/patch-3.6.4-rt11.patch.xz
The split quilt queue is available at:
http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/patches-3.6.4-rt11.tar.xz
Enjoy,
tglx
[Delta patch snipped]
--------------
http://marc.info/?l=linux-rt-users&m=135164636304684&w=2
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
23 files changed
