From owner-freebsd-arch Fri Sep 20 14:39:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC6EC37B401 for ; Fri, 20 Sep 2002 14:39:46 -0700 (PDT) Received: from 2-225.ctame701-1.telepar.net.br (2-225.ctame701-1.telepar.net.br [200.193.160.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F79643E65 for ; Fri, 20 Sep 2002 14:39:45 -0700 (PDT) (envelope-from riel@conectiva.com.br) Received: from localhost ([IPv6:::ffff:127.0.0.1]:24296 "EHLO localhost") by imladris.surriel.com with ESMTP id ; Fri, 20 Sep 2002 18:39:30 -0300 Date: Fri, 20 Sep 2002 18:39:29 -0300 (BRT) From: Rik van Riel X-X-Sender: riel@imladris.surriel.com To: Terry Lambert Cc: Julian Elischer , Bill Huey , Subject: Re: New Linux threading model In-Reply-To: <3D8B8E35.EDAF4450@mindspring.com> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 20 Sep 2002, Terry Lambert wrote: > Rik van Riel wrote: > > 1) per-cpu runqueues instead of a global one, which wants ... > Yes. > > > 2) ... load balancer between these per-cpu queues > > No. > > This is the problem with the Linux model. With an active load > balancing algorithm, you end up with global contention for > scheduler queue locks. I'm not saying you should balance all the time. It's enough to load balance once every eternity, say 1/4 of a second. Maybe a bit more often if you've got a really idle CPU. > > 3) two runqueue arrays (current and expired) instead of > > just one, which enables ... > > Not required. > > > 4) ... event-driver priority recalculation, instead of > > recalculating the priority of each task separately > > This actually doesn't work. The worst case failure is under > overload, which is exactly where you don't want it to be. What do you mean it doesn't work ? This algorithm is being used in practice and it works just fine. > The scheduling for the BSD scheduler, as was pointed out, takes > time not run into the priority weighting. The Linux O(1) scheduler uses "time not on the run queue" to determine process priority, this automatically scales when the system gets busier and busier. > A granularity of 3 seconds until the disctinction between the two queues > for enqueueing delayed jobs is realized is really gross. 8-(. Yes, it's gross. However, if your system so heavily overloaded that the sum of all timeslices of runnable processes gets larger than 3 seconds there isn't much you can do about that. kind regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Spamtraps of the month: september@surriel.com trac@trac.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message