Don't forget that you have to use preempt-kernel-rml + lock-break-rml to
achieve the same (more) than the latency patch.
Taken from Robert's page and running it for some weeks, now.
[-]
Lock breaking for the Preemptible Kernel
lock-break-rml-2.4.15-1
lock-break-rml-2.4.16-3
lock-break-rml-2.4.17-2
lock-break-rml-2.4.18-pre1-1
README
ChangeLog
With the preemptible kernel, the need for explicit scheduling points, like in
the low-latency patches, are no more. However, since we can not preempt while
locks are held, we can take a similar model as low-latency and "break" (drop
and immediately reacquire) locks to improve system response. The trick is
finding when and where we can safely break the locks (periods of quiescence)
and how to safely recover. The majority of the lock breaking is in the VM and
VFS code. This patch is for users with strong system response requirements
affected by the worst-case latencies caused by long-held locks.
[-]
Regards,
Dieter
-- Dieter Nützel Graduate Student, Computer ScienceUniversity of Hamburg @home: Dieter.Nuetzel@hamburg.de - 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/