real-time interrupts for the Linux kernel

Hi everybody!

I hope that i can steal enough of your precious time to get your attention for a new patch that adds hard real time support to the linux kernel (worst case interrupt response time below 5 microseconds):

The proposed "real time interrupt patch" enables the linux kernel for hard-real-time applications such as data aquisition and control loops by adding priorities to interrupts and spinlocks.

The following document will describe the patch in detail and how to install it:

http://home.t-online.de/home/Bernhard_Kuhn/rtirq/20040108/README

The patch and a demo application can be downloaded from:

http://home.t-online.de/home/Bernhard_Kuhn/rtirq/20040108/rtirq-20040108.tgz

Comments are highly appreciated!

best regards

Bernhard Kuhn, Senior Software Engineer, Metrowerks

...

Also,

	http://www.linuxdevices.com/news/NS3235024671.html

It's kind of a cool patch. I'm surprised that nobody's commented on this so far. Basically, if I understand this, this uses IO-APIC hardware assistance for getting some notion of prioritized interrupts and a other goodies. Just ran into the article now, but the original email post flew under my radar. /me reads more

bill

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,
Can this be used for a normal desktop?
Thanks

Bernhard Kuhn wrote:

|
| Hi everybody!
|
| I hope that i can steal enough of your precious time to get your
| attention for a new patch that adds hard real time support to the
| linux kernel (worst case interrupt response time below 5
| microseconds):
|
| The proposed "real time interrupt patch" enables the linux kernel
| for hard-real-time applications such as data aquisition and control
| loops by adding priorities to interrupts and spinlocks.
|
| The following document will describe the patch in detail and how to
| install it:
|
| http://home.t-online.de/home/Bernhard_Kuhn/rtirq/20040108/README
|
|
| The patch and a demo application can be downloaded from:
|
|
http://home.t-online.de/home/Bernhard_Kuhn/rtirq/20040108/rtirq-20040108.tgz
|
|
|
|
| Comments are highly appreciated!
|
|
| best regards
|
| Bernhard Kuhn, Senior Software Engineer, Metrowerks
|
|
|
|
|
|
|
|
|
|
|
|
| - To unsubscribe from this list: send the line "unsubscribe
| linux-kernel" in the body of a message to [email protected]
|  More majordomo info at  http://vger.kernel.org/majordomo-info.html
|  Please read the FAQ at  http://www.tux.org/lkml/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAARPskj4I0Et8EMgRAhPpAKDY3Eo6cexamFmBiQRnUZ5pJxcnwACgrseV 0v1V9e72RMQ5wD32UNDK0qc=
=E0xz
-----END PGP SIGNATURE-----

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

Thank you :-)
Liviu

Do you have actual benchmarks, and what 2.4 rather than 2.6 ?

Thanks,

Martin Schlemmer

The example kernel module and application are doing some simple benchmarking: the local APIC timer runs in period mode (1 kHz), and the interrupt handler then reads out the current value of the timer. Then you know how long it took from the occurence of the interrupt to the moment the handler has been invoked (including context switching, do_IRQ and handle_IRQ_event).

Number is my setup under heavy load (ping-flood, glxgears):

99.9% worst case
high priority 3.1 µs 5.2 µs
standard kernel 486.1 µs 500.8 µs

"99.9%" means that 99.9% of the interrupts or handled in withing the given time.

I started with 2.4 becuase that's the devil i know, but from what i have inspected so far, adopting this scheme for 2.6 should be doable within a day - i just started to work in it.

best regards

Bernhard