public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joe deBlaquiere <jadb@redhat.com>
To: yodaiken@fsmlabs.com
Cc: Andrew Morton <andrewm@uow.edu.au>, Nigel Gamble <nigel@nrg.org>,
	linux-kernel@vger.kernel.org,
	linux-audio-dev@ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0
Date: Mon, 29 Jan 2001 12:03:04 -0600	[thread overview]
Message-ID: <3A75B058.30807@redhat.com> (raw)
In-Reply-To: <200101220150.UAA29623@renoir.op.net> <Pine.LNX.4.05.10101211754550.741-100000@cosmic.nrg.org>, <Pine.LNX.4.05.10101211754550.741-100000@cosmic.nrg.org>; <20010128061428.A21416@hq.fsmlabs.com> <3A742A79.6AF39EEE@uow.edu.au> <3A74462A.80804@redhat.com> <20010129084410.B32652@hq.fsmlabs.com> <3A75A70C.4050205@redhat.com> <20010129103810.D3037@hq.fsmlabs.com>



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/

  reply	other threads:[~2001-01-29 18:06 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-07  2:53 low-latency scheduling patch for 2.4.0 Andrew Morton
2001-01-11  3:12 ` [linux-audio-dev] " Jay Ts
2001-01-11  3:22   ` Cort Dougan
2001-01-11 12:38     ` Alan Cox
2001-01-11 11:30   ` Andrew Morton
2001-01-11  5:19     ` David S. Miller
2001-01-11 13:57       ` Daniel Phillips
2001-01-11 20:55       ` Nigel Gamble
2001-01-11 21:31         ` David S. Miller
2001-01-15  5:27           ` george anzinger
2001-01-12 13:30         ` Andrew Morton
2001-01-12 15:11           ` Tim Wright
2001-01-12 22:30             ` Nigel Gamble
2001-01-13  1:01             ` Andrew Morton
2001-01-15 19:46               ` Tim Wright
2001-01-12 22:46           ` Nigel Gamble
2001-01-12 23:08           ` george anzinger
2001-01-21  0:05           ` yodaiken
2001-01-22  0:54             ` Nigel Gamble
2001-01-22  1:49               ` Paul Barton-Davis
2001-01-22  2:21                 ` Nigel Gamble
2001-01-22  3:31                   ` J Sloan
2001-01-28 13:14                   ` yodaiken
2001-01-28 14:07                     ` Bill Huey
2001-01-28 14:26                       ` Andrew Morton
2001-01-29  5:02                       ` yodaiken
2001-01-28 14:19                     ` Andrew Morton
2001-01-28 16:17                       ` Joe deBlaquiere
2001-01-29 15:44                         ` yodaiken
2001-01-29 17:23                           ` Joe deBlaquiere
2001-01-29 17:38                             ` yodaiken
2001-01-29 18:03                               ` Joe deBlaquiere [this message]
2001-01-30 15:08                           ` David Woodhouse
2001-01-30 15:44                             ` Joe deBlaquiere
2001-01-30 16:29                               ` Paul Davis
2001-01-30 16:35                                 ` David Woodhouse
2001-01-31  7:55                               ` george anzinger
2001-01-30 16:19                             ` David Woodhouse
2001-02-01 12:40                               ` Pavel Machek
2001-02-01 22:33                                 ` David Woodhouse
2001-02-02  4:17                                   ` Joe deBlaquiere
2001-01-30 20:51                             ` yodaiken
2001-01-30 21:00                               ` David Woodhouse
2001-01-29 22:08                         ` Pavel Machek
2001-01-29 22:31                         ` Roger Larsson
2001-01-29 23:46                           ` Joe deBlaquiere
2001-01-30 15:08                       ` David Woodhouse
2001-01-12 13:21       ` Andrew Morton
2001-01-13  2:45     ` Jay Ts
2001-01-21  0:10       ` yodaiken
2001-01-26  9:14         ` Pavel Machek
2001-01-13 18:11     ` video drivers hog pci bus ? [was:[linux-audio-dev] low-latency scheduling patch for 2.4.0] Jörn Nettingsmeier
2001-01-14 11:35 ` low-latency scheduling patch for 2.4.0 Andrew Morton
2001-01-14 14:38   ` Gregory Maxwell
2001-01-15 10:59     ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3A75B058.30807@redhat.com \
    --to=jadb@redhat.com \
    --cc=andrewm@uow.edu.au \
    --cc=linux-audio-dev@ginette.musique.umontreal.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nigel@nrg.org \
    --cc=yodaiken@fsmlabs.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox