On Thu, 11 Nov 1999 yodaiken@chelm.cs.nmt.edu wrote:
> > 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.
I have a set of atomic macros like in asm/atomic.h, but these are more
flexible. I'm currently designing a rt scheduler basing on them, that
will have zero interrupt latency and does even scale better, but due to
lack of time, it's far from ready yet.
Anyway, with these macros it would be possible to improve both the normal
code and interrupt latency.
> 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.
That's why I want to make interrupt handler even simpler, they should
absolutly nothing know about an interrupt controller, so that everything
can be done by the general interrupt code (may this be the normal or the
rt code).
> 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.
Complex rt systems use a multilevel approach anyway and only the hard rt
part should be in the kernel, but IMO it should look like a normal driver.
I'm not really comfortable with the idea putting a pthread interface at
kernel level, it suggest that everything works like in userspace, what
isn't true.
The soft realtime part should definitly be done in user space. Things get
better here, but here is still a lot to do...
Um, I think we can ignore the 3. point. :)
bye, Roman
-
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/