From owner-freebsd-current Tue Apr 17 10:23: 2 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 B199837B43E for ; Tue, 17 Apr 2001 10:22:57 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3HHMpt94518; Tue, 17 Apr 2001 10:22:51 -0700 (PDT) (envelope-from dillon) Date: Tue, 17 Apr 2001 10:22:51 -0700 (PDT) From: Matt Dillon Message-Id: <200104171722.f3HHMpt94518@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> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :* 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. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message