From owner-freebsd-current Tue Apr 17 13:53:42 2001 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id ECFF337B424 for ; Tue, 17 Apr 2001 13:53:38 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3HKraX24197; Tue, 17 Apr 2001 13:53:36 -0700 (PDT) Date: Tue, 17 Apr 2001 13:53:36 -0700 From: Alfred Perlstein To: Matt Dillon Cc: "Justin T. Gibbs" , Doug Barton , "'current@freebsd.org'" Subject: Re: FW: Filesystem gets a huge performance boost Message-ID: <20010417135336.Q976@fw.wintelcom.net> References: <200104160259.f3G2xqs06321@aslan.scsiguy.com> <200104160616.f3G6GI973782@earth.backplane.com> <20010417011957.W976@fw.wintelcom.net> <200104171722.f3HHMpt94518@earth.backplane.com> <20010417130210.K976@fw.wintelcom.net> <200104172051.f3HKpAF06881@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104172051.f3HKpAF06881@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Apr 17, 2001 at 01:51:10PM -0700 X-all-your-base: are belong to us. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You need to settle dude, pre-emption isn't a goal, it's mearly a _possible_ side effect. We're not aiming for pre-emption, we're aiming for more concurrancy. * Matt Dillon [010417 13:51] wrote: > : > :There's actually very little code that non-premptable once we get the > :kernel mutexed. The least complex way to accomplish this is to only > :preempt kernel processes that hold no mutex (low level) locks. > : > :-- > :-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > > I wish it were that simple. Remember when we went to shared file > descriptor arrays for processes? Half a dozen serious bugs were > introduced into the kernel from that change which weren't fixed for > over a year and half. And that was *WITH* a Giant lock left intact. > A change to a single subsystem introduced 6+ serious bugs. > > Now you guys are introducing preemptive kernel scheduling and expect > it will be a walk in the park? I expect it will introduce so many bugs > that the system will be destabilized for over a year, because that sort > of thing effects every single subsystem rather then just one or two. > > It is not going to be as simple as throwing mutexes around every little > piece of code that might access shared state somewhere. How many > mutex calls are we going to wind up making to implement the simplest > system call now? How much overhead are we going to introduce to support > a feature that isn't going to add one iota of performance to the system? > > An incredible number of very cool optimizations can be made when you > have the ability to assume that the cpu you are running under will not > get ripped out from under you. Things like per-cpu caching - not only > of mbufs or memory, but of other things as well. Simple access to > per-cpu globals now must suddenly be done with compare-exchange or > otherwise be required to use atomic instructions. None of the current > per-cpu variable handling code assumes that. > > It's just not a good idea. Do you want people to adopt -current when it > becomes 5.0? It isn't going to happen if preemptive kernel scheduling > is in there. I am going to wind up having to support 4.x for the next > two years before 5.x becomes reliable enough to use in a production > environment. Or, worse, -current is going to move down a path of > no-return (becoming so unreliable that it will not be adopted by anyone) > and we are going to wind up having to scrap the whole damn thing! > > I was somewhat skeptical about BSDI's interrupt-as-thread methodology, > but at least they didn't bite of more then they could chew when they > implemented it. Trying to extend that model to the Nth degree is > creating a huge mess -- and for what? Just to support interrupts as > threads? It isn't worth it. > > I would much rather see us changing the interrupt model to be less > invasive, thus allowing interrupts to run unhindered as interrupts > rather then threads, rather then see this preemptive kernel scheduling > stuff go in. I love SMP, but I love stability more. BSDI focused on > the things that actually effected performance. -current is not focused > at all and is going off the deep end.. trying to do things that would > be interesting work for 5.2 or 5.3 but just plain should not be in 5.0. > > -Matt -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Represent yourself, show up at BABUG http://www.babug.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message