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
On Fri, Jan 09, 2004 at 02:44:45AM +0100, 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
...
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-----
On Fri, 2004-01-09 at 03:44, 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!
>
>
Do you have actual benchmarks, and what 2.4 rather than 2.6 ?
Thanks,
--
Martin Schlemmer
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
Martin Schlemmer wrote:
> Do you have actual benchmarks,
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.
> and what 2.4 rather than 2.6 ?
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
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