Subject: [linux-audio-dev] lowish-latency patch for 2.4.0-test9
From: Andrew Morton (andrewm_AT_uow.edu.au)
Date: Fri Oct 06 2000 - 14:00:36 EEST
The little-low-latency patch for test9 is at
http://www.uow.edu.au/~andrewm/linux/2.4.0-test9-low-latency.patch
Notes:
- It now passes Benno's tests with 50% headroom (thanks to
Ingo's scheduler race fix).
- Updated to follow the wandering ext2 truncate code.
- Updated for the new VM. (I'll have to ask Rik to take a
look at this part sometime).
- Set TASK_RUNNING in conditional_schedule().
This is probably unnecessary - current->state appears to be
always equal to TASK_RUNNING in the places I'm using it.
So we test for this beforehand to avoid unnecessarily dirtying
cache lines.
(This optimisation should be done anyway, especially for SMP).
- net/ipv4/tcp_minisocks.c:tcp_twkill() can spend tens or even
hundreds of milliseconds within a timer handler. I have a
fix for this, but Alexey agrees that this needs to be
addressed independently of the low-latency patch. So this file
is untouched.
- This entire feature has been *disabled* for SMP. This patch
is now UP-only.
It is completely stable on SMP and the scheduling latency is
just grand, as long as you don't push things too hard. It
then comes unstuck.
This is because of the following scenario:
* CPU1 holds a long-lived spinlock such as dcache_lock
in select_parent().
* CPU0 is spinning on the same lock.
* An interrupt occurs and the kernel tries to wake up
your SCHED_FIFO task on CPU0.
You lose. Nothing happens until CPU1 releases the lock
a week later.
There are a number of ways of fixing this, but they're
messy.
One way is to identify those locks and to add a test for
current->need_resched into the spin. This gets nastier
if the BKL is held at the same time.
Another way is to write a fully-preemptible SMP kernel
patch :)
This archive was generated by hypermail 2b28 : Fri Oct 06 2000 - 14:22:28 EEST