Subject: Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0
From: Joe deBlaquiere (jadb_AT_redhat.com)
Date: Mon Jan 29 2001 - 19:23:24 EET
Good morning world! :o)
yodaiken_AT_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
This archive was generated by hypermail 2b28 : Tue Jan 30 2001 - 17:12:27 EET