From owner-freebsd-current Tue Apr 17 13: 2:27 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 A658837B43E for ; Tue, 17 Apr 2001 13:02:13 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3HK2A222352; Tue, 17 Apr 2001 13:02:10 -0700 (PDT) Date: Tue, 17 Apr 2001 13:02:10 -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: <20010417130210.K976@fw.wintelcom.net> References: <200104160259.f3G2xqs06321@aslan.scsiguy.com> <200104160616.f3G6GI973782@earth.backplane.com> <20010417011957.W976@fw.wintelcom.net> <200104171722.f3HHMpt94518@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: <200104171722.f3HHMpt94518@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Apr 17, 2001 at 10:22:51AM -0700 X-all-your-base: are belong to us. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Matt Dillon [010417 10:22] wrote: > > :* Matt Dillon [010415 23:16] wrote: > :> > :> For example, all this work on a preemptive > :> kernel is just insane. Our entire kernel is built on the concept of > :> not being preemptable except by interrupts. We virtually guarentee > :> years of instability and bugs leaking out of the woodwork by trying to > :> make it preemptable, and the performance gain we get for that pain > :> is going to be zilch. Nada. Nothing. > : > :Pre-emption is mearly a side effect of a mutex'd kernel. > : > :The actual gains are in terms of parallel execution internally. > :Meaning if we happen to copyin() a 4 meg buffer we can allow more > :than one process to be completing some sort of work inside the > :kernel other than spinning on the giant lock. > : > :-- > :-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > > Switching-away while obtaining giant lock isn't a big deal, and > not really 'preemption'. Switching a task out in the middle of > some random piece of code is preemption and our system isn't designed > to handle it. By trying to implement it, you are virtually guarenteed > to introduce hundreds of bugs that will take years to find and fix. > > My understanding of the original BSDI code was that an interrupt could > preempt the current process, but on completion (or if the interrupt > blocked) the current process would resume on the same cpu... that > is, the BSDI system only preempted for interrupts, which our > codebase can accomodate just fine. > > I can see us doing some fancy process switching to avoid spinning on > the giant lock. But I can't see us reliably preempting a process sitting > in some random piece of kernel code. 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] 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