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

[Joe deBlaquiere]

[e-mail] wrote:

> On Mon, Jan 29, 2001 at 11:23:24AM -0600, Joe deBlaquiere wrote:
> 
>> while (!done)
>> {
>> 	done = check_done();
>> }
>> 
>> when you can have:
>> 
>> while (!done)
>> {
>> 	yield();
>> 	done = check_done();
>> }
> 
> 
> But there is a reason for the first: time. 
> 
> while(!read_pci_condition); // usually finishes in 10us
> 
> versus
> 
> while(!read_pci_condition)yield(); // usually finishes in 1millisecond
> 
> can have a nasty impact on system performance. 
> 
>       

So perhaps you check need_resched first, but it all boils down to how 
many 10 us delays you're going to take. If you start taking too many 
you're just gratuitously sucking the V+ line without meaningful results. 
It all really depends on how much you actually expect to wait. There is 
unfortunately no way at the present to quantify all these delays and 
tune the system to the performance requirement. You could try something 
like (no, i didn't compile this, so don't expect it to work) :

#define EXPECTED_TIMEOUT(x,y)	( (x) > CONFIG_DRIVER_TIMEOUT_MAX ? (y) : (0) )

while (!done)
{
	EXPECTED_TIMEOUT(50,yield());
	done = check_done();
}

to tune these delays in or out of the kernel based on a kernel config 
parameter. If you are willing to tolerate a longer delay the driver 
itself can run faster, whereas if you force the system to yield, then 
this favors the other threads. (I'm not advocating we litter the entire 
kernel with gobs of nested macros either, just that there should be some 
way to do it right).

> 
>> 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.
> 
> 
> Not a cheap vehicle.  Linux is pretty snappy on an AMD SC420  or
> a M860 and 5 meg of memory. And it scales to a quad xeon well. Don't
> try that with IRIX.  
> So to push my tired metaphor even further beyond
> the bounds, a delivery van that needs jet fuel and uses two lanes, 
> won't do well in the delivery business no matter how well it 
> accelerates.

So how about we just put a knob on the dash and make it scale from 
delivery van to sports car based on the needs of one particular system. 
I realize there will be boundaries, but that's what you and I have jobs, 
to solve the boudary cases. The more flexible the kernel is, the easier 
it is to adapt to the extremes.

--
Joe