Messages in this thread | | | Date | Mon, 29 Jan 2001 11:23:24 -0600 | From | Joe deBlaquiere <> | Subject | Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0 |
| |
Good morning world! :o)
yodaiken@fsmlabs.com wrote:
> Only if your RTLinux application is running. In other words, you cannot > commit more than 100% of cpu cycle time and expect to deliver. > I think one of the common difficulties with realtime is that time-shared > systems with virtual memory make people used to elastic resource > limits and real-time has unforgiving time limits. > >
The problem I see is not one of cpu 'overcommit' but of 'critical sections' in the driver code. I really like the preemptive model, but it would seem to me that there needs to be a way to cooperate with some of the driver code. Allowing the driver a brief exclusive time share does certainly have latency implications, but breaking drivers can crash things pretty quickly (If you're running a program XIP from flash and a RT interrupt leaves the flash in a unreadable state, boom!). If the answer is to run the 'critical' driver code as a RT thread, I can live with that, but there should be a clear policy and mechanism in place to handle it.
> > > Or what is the tradeoff or whether a deadlock will follow. > step 1: memory manager thread frees a few pages and is courteous > step 2: bunch of thrashing and eventually all processes stall > step 3: go to step 1 > > alternative > step 1: memory manager thread frees enough pages for some processes to > advance to termination > step 2: all is well > > and make up 100 similar scenarios. And this is why "preemptive" > OS's tend to add such abominations as "priority inheritance" which > make failure cases rarer and harder to diagnose or complex schedulers > that spend a significant fraction of cpu time trying to figure out > what process should advance or ... > >
It doesn't matter how you do it, the cooperative model eventually starts to feel like Windoze3.1 in the extreme case, but even so, it was much more multithreaded than DOS. Of course, the Right Thing (TM) is to do away with the cooperative model. But even in a preemptive model, there's no reason to have code like
while (!done) { done = check_done(); }
when you can have:
while (!done) { yield(); done = check_done(); }
being preemptive and being cooperative aren't mutually exclusive.
Borrowing your sports car / delivery van metaphor, I'm thinking we could come up with something along the lines of a BMW 750iL... room for six and still plenty of uumph.
Cheers,
Joe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |