From owner-freebsd-chat Wed Oct 17 13:39:26 2001 Delivered-To: freebsd-chat@freebsd.org Received: from femail15.sdc1.sfba.home.com (femail15.sdc1.sfba.home.com [24.0.95.142]) by hub.freebsd.org (Postfix) with ESMTP id 25B5B37B435 for ; Wed, 17 Oct 2001 13:39:17 -0700 (PDT) Received: from laptop.baldwin.cx ([24.2.39.156]) by femail15.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20011017203915.VGZT2467.femail15.sdc1.sfba.home.com@laptop.baldwin.cx>; Wed, 17 Oct 2001 13:39:15 -0700 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <4.3.2.7.2.20011017120858.046a58a0@localhost> Date: Tue, 16 Oct 2001 22:13:47 -0700 (PDT) From: John Baldwin To: Brett Glass Subject: Re: Breaking news: FreeBSD is "considering implementing a preemp Cc: chat@FreeBSD.ORG, Dag-Erling Smorgrav Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 17-Oct-01 Brett Glass wrote: > At 09:40 AM 10/16/2001, Dag-Erling Smorgrav wrote: > >>Robert Love is writing a patch to make the Linux kernel preemptible, >>and has some interesting ideas about FreeBSD: >> >>http://kerneltrap.com/article.php?sid=328&mode=thread&order=0 > > Kernel pre-emption is tough to retrofit into a kernel, but not hard > to put in if you're writing one from scratch. SVS' "Integrity" > (http://www.ghs.com/products/rtos/integrity.html) has had it for > quite some time. The RTOS never turns off interrupts, though it does > ignore those that come in while a previous interrupt from the same > source is being handled. Actually, it's not that hard at all with interrupt threads already in place in -current. You just do a simple check in setrunqueue() to see if you should switch to the new thread/process when it's put on the runq (i.e. is its priority higher than your current thread/process.) The only remaining trick is to not preempt during critical sections which are already marked by our critical_enter/exit API. Basically, if we are in a critical section, then setrunqueue() sets a flag in the current thread rather than switching, and when we call critical_exit() to exit the critical section we switch if that flag is set (i.e. we delay the preemption until we exit the critical section). It actualy is fairly simple, and it removes things like the MTX_NOSWITCH flag and the SWI_SWITCH/SWI_NOSWITCH flags thus simplifying some interfaces. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message