Date: Tue, 17 Apr 2001 13:53:36 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Matt Dillon <dillon@earth.backplane.com> Cc: "Justin T. Gibbs" <gibbs@scsiguy.com>, Doug Barton <DougB@DougBarton.net>, "'current@freebsd.org'" <current@FreeBSD.ORG> Subject: Re: FW: Filesystem gets a huge performance boost Message-ID: <20010417135336.Q976@fw.wintelcom.net> In-Reply-To: <200104172051.f3HKpAF06881@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Apr 17, 2001 at 01:51:10PM -0700 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <dillon@earth.backplane.com> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010417135336.Q976>