Subject: Re: Floating point in the kernel
To: None <email@example.com>
From: Charles M. Hannum <firstname.lastname@example.org>
Date: 09/22/1998 19:48:23
BTW, some random notes on doing `real-time' support:
* Other timing constraints aside, Curt's `limit CPU to 80%' isn't
conceptually different from a deadman switch, and could be
implemented in the same fashion (i.e. one-shot fires and forces a
context switch). Of course it has to be documented and
configurable, but that's a different issue.
* With I/O threads, it should actually be possible to disable hardware
interrupts for devices whose I/O threads are at a lower priority
than the currently running task. I haven't implemented this, and I
don't have any plans to, but someone else could.
* You'd still want to prevent clock interrupts from causing jitter.
Probably the simplest thing to do is either get rid of the absolute
time reference or put it in hardware. If you have a fixed maximum
scheduling interval (as mentioned above), you could also use a
smaller free-running counter and check it for rollover on each
switch, as well as scheduling the timeout for the next task switch.
(NextStep does something like this.)
* You still have to get rid of other jitter sources -- including the
MMU/TLB and caches. The big one here is the MMU. It's not enough
to just mlock() everything, because you're still using the TLB,
which introduces an element of randomness. The solution to this is
really the same as for `embedded' MMU-less systems: link everything
as PIC code, so it can be loaded anywhere, get rid of all other
fixed memory addresses (primarily the location of the stack), and
run everything in a single address space.
It'd actually be nifty if someone worked on this -- particularly the
last part -- mainly because it would enable NetBSD to run on small
embedded systems like printers and Pilots.