Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1

[Esben Nielsen]

On Thu, 14 Oct 2004, Ingo Molnar wrote:

> 
> * Mark_H_Johnson@xxxxxxxxxxxx <Mark_H_Johnson@xxxxxxxxxxxx> wrote:
> 
> > >the overhead we can try to optimize later on. What problems do you see
> > >with setting priorities on those IRQs?
> > 
> > Perhaps I am old fashioned, but in building a real time system, I
> > consider hardware interrupt processing as something that is always at
> > a higher priority than real time tasks. [...]


Let us say you have a server taking in requests over the network. Then you
want to run the ethernet device at very high priority - you can just as
well run it in the interrupt directly. But let us say you are making an
embedded device handling some hardware real-time but having a
web-interface to configure it. Then you dont want the traffic on the
network to take CPU from you real-time thread (if you don't have DMA it
can take a lot of CPU just to read the packets out of the controller!)

I do have real life experience with exactly this problem and the solution
was to move the interrupt-handler into a low-priority thread.

As I said on comments on lwn.net: Make these things parameters for the
real-time guys to choose per driver for their specific system. There is no
good setting useable for everybody. On normal systems let them stay in
interrupt context and use normal spinlocks for must things That _performs_
much better but gives higher latencies. Just make it possible for the
real-time system developeres to configure their system compiletime along
with choosing drivers, file systems etc.


Esben



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/