Messages in this thread | | | Date | Sun, 25 Jul 1999 20:20:06 +0200 | From | David Olofson <> | Subject | Re: real-time threaded IO with low latency (audio) |
| |
yodaiken@chelm.cs.nmt.edu wrote: > > On Sun, Jul 25, 1999 at 01:38:12AM +0200, David Olofson wrote: > > Well, what I'm looking for is a way to use RTLinux as a high priority RT > > scheduler that can switch to user context in order to execute code while > > still in RT context with regard to timing. In that case, Linux can even > > be completely frozen! RT tasks would still run, just as is the case with > > RTLinux, provided EVERYTHING is really in locked memory. > > I've considered doing it but we need to exit the RT context on > 1. system call
Ok, but it's up to the programmer and libraries to stay away from system calls, as they turn the application into a soft real time one anyway.
> 2. page fault - stacks can cause 'em even after mlockall
That's what I was afraid of... Cannot this be fixed in any reasonable way? (Is it related to dynamic stack allocation?)
> 3. any other trap or error condition that puts us in K mode.
Does this need to be handled without losing the RT timing, or is it "just" a matter of handling it to keep RT an error condition from causing a bad crash?
> The methods I've thought of for doing this are unpleasant.
What's the biggest problems here? Too much context info to keep track of in order to separate RT from standard Linux? I'll have a closer look at the low level areas of the standard scheduling code to get a better idea of what's going in, but I'm not expecting a pleasant surprize...
//David
- 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/
| |