Messages in this thread |  | | | Date | Fri, 12 Nov 1999 09:55:23 +0100 (MET) | | From | Roman Zippel <> | | Subject | Re: linux interrupt handling problem |
| |
Hi,
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/
|  |