From owner-freebsd-arch Fri Sep 20 13: 0:18 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 2188E37B404 for ; Fri, 20 Sep 2002 13:00:16 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5781143E65 for ; Fri, 20 Sep 2002 13:00:15 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020920200014.MQHV28420.sccrmhc03.attbi.com@InterJet.elischer.org>; Fri, 20 Sep 2002 20:00:14 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA20419; Fri, 20 Sep 2002 12:59:57 -0700 (PDT) Date: Fri, 20 Sep 2002 12:59:57 -0700 (PDT) From: Julian Elischer To: Rik van Riel Cc: Gary Thorpe , freebsd-arch@freebsd.org Subject: Re: New Linux threading model In-Reply-To: Message-ID: 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, Rik van Riel wrote: > On Fri, 20 Sep 2002, Gary Thorpe wrote: > > > So what happens if a processes has been sitting in the > > queue waiting for a very long time: depending of the > > scheduling algorithm, it may need to have its priority > > increased the longer it waits but this will not > > happen...until it is scheduled? Can this lead to > > starvation? > > Nope, the O(1) scheduler has some tricks to avoid > starvation. The main thing here is that it uses > 2 priority arrays, one for tasks that have time in > their current time slice left (current) and one > or tasks that have run out of time slice (expired). > > As long as the tasks on the expired queue aren't > being starved yet, interactive tasks hop on and off > the current priority array and the expired tasks > just sit there ... > > ... but once the oldest task on the expired array > has been sitting there for some time (default is 3 > seconds, I think) the kernel will add newly woken > up tasks to the expired array. > > It will keep running the tasks from the current > array until the time slices are all gone and then > it switches arrays, running tasks from the expired > array. > > No starvation. > > > > There don't seem to be any O(n) loops left in or > > > near this scheduler, > > > meaning that 1:1 threading with lots of threads > > > becomes possible. > > > > The maximum parallelism on a given SMP system can > > never be more than the number of CPUs so wouldn't a 1 > > : 1 model lead to unnecessary overhead? > > Your threads never block on IO ? Or page faults, for that matter ? Ah yes but in KSE, just the thread blocks and an upcall gives the CPU back to the userland scheduler to run another thread shoudl ther ebe one ready.. > > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message