Date:	Fri, 06 Oct 2000 22:00:36 +1100
From:	Andrew Morton <andrewm@uow.edu.au>
To:	lkml <linux-kernel@vger.kernel.org>,
Subject: lowish-latency patch for 2.4.0-test9

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 :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/