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

From: Joe deBlaquiere (jadb@redhat.com)
Date: Mon Jan 29 2001 - 13:03:04 EST


yodaiken@fsmlabs.com 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

- 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/



This archive was generated by hypermail 2b29 : Wed Jan 31 2001 - 21:00:33 EST