Linus Torvalds wrote:
> Note that these issues are completely off the map of what is really
> meaningful at this point.
>
> We want to avoid having long latencies, and we can easily get that by just
> allowing timer interrupts to schedule which we're in a big
> "memcpy_to_user()" and we don't hold any kernel lock etc. No need to try
> to be clever at lock release time - if we get a pending reschedule, we
> might as well leave it pending, it's going to be serviced soon enough
> anyway.
Ingo's bog standard low-latency patch is already said to do a fine job
down to 0.5ms or so, and it does what you suggest.
The problem remains with various bits of code that aren't audited for
low latency (there will always be some). Drivers that spend ages in a
loop (see recent fbcon thread for example). Random bits of
uninteresting vfs or mm code that haven't been examined.
These off-the-map issues are designed to address that stuff. To do what
the low latency patch does, but guarantee it works everywhere. Assuming
none of the unaudited code holds a spinlock for ages.
So you can have a high priority thread that can process audio in real
time (for example), or a softmodem user space driver (other completely
random example). Note that RTLinux isn't really suitable for those --
RTLinux isolates the real time process too much. And super-hard isn't
required for those applications anyway.
You suggestion of timer interrupts would actually be good enough for
audio and softmodem apps, if you crank up the timer to 1kHz. So would
the device interrupts probably.
But the idea of only preempting during memcpy_to_user isn't enough --
some code loops for ages and it's not doing memcpy_to_user.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:26 EST