Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0

[Joe deBlaquiere <jadb@redhat.com>]

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/