Re: [announcement, patch] real-time interrupts for the Linux kernel

[Voicu Liviu <pacman@mscc.huji.ac.il>]

Thank you :-)
Liviu

Bernhard Kuhn wrote:

> Voicu Liviu wrote:
>
>> Can this be used for a normal desktop?
>
>
> I don't think that real time interrupts are usefull for
> a desktop environment: here, even interrupt latencies
> below one millisecond should be more than good enough for
> streaming/multimedia applications and games - if your
> specific application is not "fast" or "reactive" enough,
> i would tend to say that it is not the fault of the linux
> kernel and it's the implementation of the application
> itself or one of the related kernel drivers that needs
> improovment. If you recognize interrupt response times
> higher than a millisecond with a standard linux kernel,
> then there is definitly a bad device driver or something
> is broken with your hardware.
>
> The real time interrupt patch is mostly intended to be
> used in control loop and data aquisition applications
> where higher latencies or jitters higher than a few
> mirocseconds could have catastrophic consequences.
> However, i can imagine that it makes sense to use
> this patch for some very special networking devices
> where the kernel might sometimes not be able to response
> quick enough because it is just processing an
> interrupt of type SA_INTERRUPT that takes too much
> time. But in these cases, i guess it's simpler to fix
> that other device driver (by moving parts of the interrupt
> handler to a tasklet) rather than introducing
> real time interrupts - the only problem with this
> variant is that for oftenly changing hardware
> configurations, you can never be sure if you catched
> all "longest execution paths" and you may end up
> spending most of your time improving other device
> drivers.
>
> BTW.: having interrupt priorities is only the first
> step to make the kernel hard real time aware. The
> next step would be to make the kernel scheduler
> re-entrentable, so that a user space application
> related to a high priority interrupt could run
> at a higher priority than a low level interrupt service
> routine (low priority interrupts are disabled while the
> high priority application is running) - this scheme
> is pretty similar to LXRT, except that the kernel scheduler
> is used instead of an external dispatcher. But just
> as like as with LXRT, you only have a very limited
> set of system calls and you can easly lock up your system
> when an application takes 100% of the CPU.
>
> best regards
>
> Bernhard