From owner-freebsd-current Tue Apr 17 13:51:23 2001 Delivered-To: freebsd-current@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 19DEE37B440 for ; Tue, 17 Apr 2001 13:51:15 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3HKpAF06881; Tue, 17 Apr 2001 13:51:10 -0700 (PDT) (envelope-from dillon) Date: Tue, 17 Apr 2001 13:51:10 -0700 (PDT) From: Matt Dillon Message-Id: <200104172051.f3HKpAF06881@earth.backplane.com> To: Alfred Perlstein Cc: "Justin T. Gibbs" , Doug Barton , "'current@freebsd.org'" Subject: Re: FW: Filesystem gets a huge performance boost 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> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message