Date: Fri, 20 Sep 2002 13:13:17 -0400 (EDT) From: Gary Thorpe <gathorpe79@yahoo.com> To: Rik van Riel <riel@conectiva.com.br> Cc: freebsd-arch@freebsd.org Subject: Re: New Linux threading model Message-ID: <20020920171317.77976.qmail@web11207.mail.yahoo.com> In-Reply-To: <Pine.LNX.4.44L.0209201112230.1857-100000@imladris.surriel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--- Rik van Riel <riel@conectiva.com.br> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020920171317.77976.qmail>