Messages in this thread | | | Date | Mon, 29 Jan 2001 12:03:04 -0600 | From | Joe deBlaquiere <> | Subject | Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0 |
| |
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/
| |