From owner-freebsd-arch Wed Nov 21 18:42: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 45D0C37B418 for ; Wed, 21 Nov 2001 18:41:55 -0800 (PST) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id fAM2ftM53200 for ; Wed, 21 Nov 2001 18:41:55 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 868CF3811; Wed, 21 Nov 2001 18:41:55 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Alfred Perlstein Cc: Julian Elischer , arch@FreeBSD.ORG Subject: Re: Kernel Thread scheduler In-Reply-To: <20011121184508.T13393@elvis.mu.org> Date: Wed, 21 Nov 2001 18:41:55 -0800 From: Peter Wemm Message-Id: <20011122024155.868CF3811@overcee.netplex.com.au> 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 Alfred Perlstein wrote: > * Julian Elischer [011121 18:40] wrote: > > > > > > Peter, John (Baldwin) and I got to gether yesterday and thrashed > > out the mechanisms behind the KSE/thread scheduler. > > This allows us to go ahead and start coding again, now that we know what > > we are aiming at. > > > > Here is the basic mechanism. > [snip] > > Since my request is about one one thousandth as complex as this I'm > just going to ask: > > Will this stuff be usable as a lightweight mechanism inside the kernel? We talked doing a "raw" implemetation first without the userland glue (like rfork is "raw" with no sync mechanisms etc). If we have this basic functionality first then we should be able to glue it onto kthread pretty easily. > Case in point, could nfsd be changed to only have one process (instead > of many) while still being able to block and get an upcall? In theory yes. The thing is though that nfsd doesn't really run in userland so it doesn't really buy us much. It just gives us a slightly less overhead way of popping new contexts into and out of existence. What's really needed is for nfsd to self manage. All the userland process is needed for is creating and binding the listen sockets, and holding them open while the kernel has fun with them. It shouldn't have to create $n processes in advance "in case" they are needed. The kernel side should be able to add/remove nfsd contexts in response to load (and some limits). Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message