The little-low-latency patch for test9 is at
- 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
(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
- 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
* 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
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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Oct 07 2000 - 21:00:19 EST