From owner-freebsd-arch Fri Sep 20 10:13:23 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 4E74E37B401 for ; Fri, 20 Sep 2002 10:13:21 -0700 (PDT) Received: from web11207.mail.yahoo.com (web11207.mail.yahoo.com [216.136.131.189]) by mx1.FreeBSD.org (Postfix) with SMTP id 126A643E4A for ; Fri, 20 Sep 2002 10:13:21 -0700 (PDT) (envelope-from gathorpe79@yahoo.com) Message-ID: <20020920171317.77976.qmail@web11207.mail.yahoo.com> Received: from [142.204.207.93] by web11207.mail.yahoo.com via HTTP; Fri, 20 Sep 2002 13:13:17 EDT Date: Fri, 20 Sep 2002 13:13:17 -0400 (EDT) From: Gary Thorpe Subject: Re: New Linux threading model To: Rik van Riel Cc: freebsd-arch@freebsd.org In-Reply-To: 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 --- Rik van Riel wrote: [...] > What's maybe more important about the O(1) scheduler > is that it > doesn't try to recalculate the priority of all > processes once > in a while, like the FreeBSD scheduler and the old > Linux scheduler. 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? I.e. will a waiting process never have its priority increased enough to be scheduled because it needs to be scheduled in order to have its priority increased? > > 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? Why have hundreds of kernel threads when the system can only run two or four in parallel? Even the largest SMP machines (not NUMA machines like SGI's Origin) don't have more than a hundred cpus. > > > > What they have decided to do is not a stupid > move. But I disagree with > > > > It's a good political move on their part because > of the orientation of > > their kernel community. Their kernel context > switching time is very > > fast, 2x faster than NetBSD from what I saw, so > it's probably a workable > > solution for them with something like their > "futex" performance being > > the only funny question left unanswered. > > Futexes are very nice. In the uncontended case > (should be the > normal case, if your semaphores are always contended > you've got > worse problems) there is NO kernel overhead involved > in grabbing > the lock ... you just do the same atomic operations > involved with > grabbing a spinlock. > > Only in the contended case will a futex fall back to > sleeping in > kernel space. > > This kind of very low overhead locking might be > useful for FreeBSD > too, if it isn't yet integrated into the KSE model. > > As for which threading model to use ... I wouldn't > worry about that > too much, I suspect either the Linux 1:1 model or > the M:N model used > by KSE will work just fine for pretty much all > applications. > > cheers, > > 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 ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message