From owner-freebsd-arch@FreeBSD.ORG Tue Mar 16 08:07:03 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6EA916A4CF for ; Tue, 16 Mar 2004 08:07:03 -0800 (PST) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E4AB43D48 for ; Tue, 16 Mar 2004 08:07:03 -0800 (PST) (envelope-from john@baldwin.cx) Received: (qmail 20171 invoked from network); 16 Mar 2004 16:06:52 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 16 Mar 2004 16:06:52 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i2GG5m29065141; Tue, 16 Mar 2004 11:06:01 -0500 (EST) (envelope-from john@baldwin.cx) From: John Baldwin To: arch@FreeBSD.org Date: Tue, 16 Mar 2004 10:12:09 -0500 User-Agent: KMail/1.6 References: <1077137806.28133.10.camel@herring.nlsystems.com> <20040316142110.GA6802@technokratis.com> <1079448788.10695.1.camel@builder02.qubesoft.com> In-Reply-To: <1079448788.10695.1.camel@builder02.qubesoft.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403161012.09174.john@baldwin.cx> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Bosko Milekic cc: freebsd-arch@FreeBSD.org Subject: Re: Read Copy Update X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2004 16:07:04 -0000 On Tuesday 16 March 2004 09:53 am, Doug Rabson wrote: > On Tue, 2004-03-16 at 14:21, Bosko Milekic wrote: > > On Tue, Mar 16, 2004 at 09:14:51AM +0000, Doug Rabson wrote: > > > On Tuesday 16 March 2004 03:17, Bosko Milekic wrote: > > > > On Thu, Feb 19, 2004 at 09:02:35AM +0000, Doug Rabson wrote: > > > > > On Wed, 2004-02-18 at 23:26, Jeff Roberson wrote: > > > > > > I think that this is a good path to go down, but I really don't > > > > > > think we're ready yet. I'd rather see energy spent protecting > > > > > > code than building more infrastructure. > > > > > > > > > > I completely agree. I was just musing about this as a future > > > > > addition to the locking toolbox. Its certainly not worth trying > > > > > before enough of the kernel is outside the giant lock to make it > > > > > worthwhile. > > > > > > > > As Jeff said and you agree, it is probably too early for this now. > > > > Also, I've looked at the paper you quote before SCO's announcement > > > > (which by the way I had no idea about until now), and I think we'll > > > > eventually do just as well in the common case without going to the > > > > RCU model at all. > > > > > > Its a pretty neat idea though. I like the sound of being able to e.g. > > > read from the namecache without needing to take an expensive lock. With > > > the way 5-CURRENT works, we would probably still need to suppress > > > context switching which is expensive on intel processors in the current > > > implementation. I guess that could be fixed using some kind of lazy-cli > > > scheme. > > > > Should be really easy to fix in the common case without having to get > > really fancy (e.g., just interlock against ourselves on a private > > per-thread flag) to merely delay cli until the first interrupt. We > > shouldn't need to mask out per CPU or anything fancy like that. > > I was imagining a a pcpu flag which was a 'soft cli', i.e. if a cpu > fields an interrupt and the soft cli flag is set, it just clears the > interrupt flag in the trapframe and returns. It all works out the same > in the end. I have this partly implemented, but because the VM86 code really sucks (it just always enables interrupts) the invariants checks I have don't make it to single user mode. I haven't decided what to do about VM86 yet, and I also haven't handled the problem of switching away from interrupt context (for ithread preemption) and switching back and making that all work correctly w/o possibly dropping interrupts. -- John Baldwin <>< http://www.baldwin.cx/~john/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org