Re: a joint letter on low latency and Linux

Andrea Arcangeli (andrea@suse.de)
Fri, 30 Jun 2000 20:09:42 +0200 (CEST)


On Thu, 29 Jun 2000, Linus Torvalds wrote:

>I definitely agree with low-latency requirements even in a standard Linux.

Agreed. The faster a task with current->need_resched set to 1 is
rescheduled, the better. We just care very much about this in
reschedule_idle (if we wouldn't care about latency we could as well drop
such part of reschedule_idle ;).

>I just disagree violently with doing them with horrible cludges instead of
>working on doing it right.

BTW, I think for some of the other cases that are in the lowlatency-patch
in 2.2.x, we just do them better in 2.4.x without explicit runtime checks
on need_resched. Often doing the right thing to fix the latency we also
achieve throughput (for example with the page-LRU in shrink_mmap).

I think RT linux is sure the right way to go if all the RT work is done
inside an interrupt. For example if you have to control the walk of a
robot and you get interrupt at completation of each step, then you can
drive the robot to do the next step inside the same interrupt handler. If
the robot won't do the next step in a deadline it will crash on the
ground. Having a minimal fixed latency in the irq handler means that you
can load the machine as you want in background and the robot will never
crash. This can't be garanteed if we allow any kernel driver to issue a
real asm("cli") and there are definitely applications that needs the
garantee so I see RT linux useful for them. Usually they're embedded
applications.

If we instead want to do the calculation for the next step in userspace
(as in the multimedia case) the thing is quite different and actually I
don't know how RT linux iteracts with the linux scheduler and how it can
provide zero latency in rescheduling to a regular linux task that is
supposed to be able to run syscalls and so on.

Another very clean solution to drop completly the latency is to bind the
application to a single CPU disallowing any other application to run on
that CPU (this hurts very much global system performance but it will
provide zero reschedule latency to such task because its CPU will be
always idle unless the task itself is just running on it ;).

Andrea

-
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/