Date: Tue, 17 Apr 2001 13:02:10 -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: <20010417130210.K976@fw.wintelcom.net> In-Reply-To: <200104171722.f3HHMpt94518@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Apr 17, 2001 at 10:22:51AM -0700 References: <200104160259.f3G2xqs06321@aslan.scsiguy.com> <200104160616.f3G6GI973782@earth.backplane.com> <20010417011957.W976@fw.wintelcom.net> <200104171722.f3HHMpt94518@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Matt Dillon <dillon@earth.backplane.com> [010417 10:22] wrote: > > :* Matt Dillon <dillon@earth.backplane.com> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010417130210.K976>