lkml.org 
[lkml]   [1999]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: linux interrupt handling problem
On Thu, Nov 11, 1999 at 05:26:20PM +0100, Roman Zippel wrote:
> Hi,
>
> On Thu, 11 Nov 1999 yodaiken@chelm.cs.nmt.edu wrote:
>
> > It's quite simple to connect Linux non-rt processes to RT tasks and
> > handlers in RTLinux. In fact, the entire purpose of RTLinux is to make
> > the "unix system" accessible to the RT layer.
> > However, we do not do what Solaris and other operating systems do, which
> > is "integrate" the realtime into the rest of the kernel by slowing down
> > the rest of the kernel and making the realtime part not realtime.
>
> I don't want that too, but there is still room for improvement. IMO it's
> possible to integrate the realtime part better into Linux, so it's
> possible to use more Linux services directly from RTLinux and the

How? This is something that seems very difficult to me and I'd be happy
to see how it could be done well.

> hardrealtime part could be a normal Linux driver. I don't think this has

I don't see how. Certanly you can get a kind of pseudo RT with a device driver
approach, and certainly if you turn Linux synchronization into a horrible
nightmare, you can allow for certain "rt" interrupts to have low latency.
But in this case you (A)make interrupt controller dependencies visible
throughout code , (B) make the general case run slower, and (C) make the
main kernel impossible to debug or maintain.


> to be slower, but the important part would be to make the user space
> realtime part more responsive, there of course would be a small price, but
> that could be disabled by a config option.

It's important to keep in mind the different kinds of realtime.
1. Hard realtime: Guaranteed limits on interrupt latency and RT periodic task
jitter. This is what RTLinux provides.
2. Soft realtime: Statistical measure of success.
3. Marketing realtime: Whatever you want it to mean.


(2) is an interesting problem that I am starting to believe must be addressed
via a solution for (1). But (1) has nothing to do with more responsive user
space processes. In fact "more responsive" is absolutely unrelated to hard
realtime. In Linux, "more responsive" is an average measurement: over a period
of time, processes generally run within T time units of becoming runnable.
In hard realtime, we care about the worst case.


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

\
 
 \ /
  Last update: 2005-03-22 13:54    [from the cache]
©2003-2011 Jasper Spaans