From owner-freebsd-arch@FreeBSD.ORG Wed May 26 14:27:29 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 BD6A116A4CE for ; Wed, 26 May 2004 14:27:29 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FF5A43D41 for ; Wed, 26 May 2004 14:27:29 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i4QLQVU4026244; Wed, 26 May 2004 17:26:31 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i4QLQVff026241; Wed, 26 May 2004 17:26:31 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 26 May 2004 17:26:31 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Matthew Dillon In-Reply-To: <200405251829.i4PITjbp093921@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: Alan Cox Subject: Re: Network Stack Locking 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: Wed, 26 May 2004 21:27:29 -0000 On Tue, 25 May 2004, Matthew Dillon wrote: > This sounds very similar to an interrupt mechanism I designed about > a decade ago. Instead of saving and restoring the interrupt > context for the interrupt thread, the thread switch was special-cased > to basically create a context (by pushing a procedure call on the stack) > on switch-in and to throw it away on switch-out (which was always at > the end of the interrupt routine). I extended the same mechanism down > into 'userland' by creating a 'waitforever()' system call which basically > did nothing but wait for and dispatch signal vectors (most of the programs > were event oriented and had no main loop). The nice thing about this was > that no context had to be saved while the program was sitting in > waitforever(), or restored when the program returned from a signal handler. > This more then doubled scheduler performance (which on a 10MHz 68000 was > important). > > In many ways, the continuation mechanism and the message queue mechanism > appear to be nearly identical. If an explicit exit from a procedure > is required to optimize the stack with the continuation mechanism, then > that isn't much different then moving the message to an event queue > and returning to the message processing loop. Neither case allows > you to save stack context or to save the current procedural stacking > level, and both mechanisms allow you to reuse your current stack to > handle multiple messages/continuations. I'm not sure if you've spent much time looking at the Mach kernel and literature, but a lot of the concepts in AmigaOS and DFBSD are highly parallel to concepts in Mach (and hence in many derived systems). The original Mach project at CMU (from about 1985-1993) still has a web page: http://www-2.cs.cmu.edu/afs/cs/project/mach/public/www/mach.html I don't remember if there's specifically a paper on continuations there, but it should be discussed in their developer guides, threading and parallelism bits, and documentation of their scheduler. There's also been follow-up work on Mach in a great many environments, including work at OSF, University of Utah (FLUX, etc), by the GNU folks on Hurd, NeXT, Apple, et al. There's also been follow-up work at CMU on real time scheduling in Mach. The reason I tend to raise aspects of Darwin when responding to your e-mails regarding DFBSD is that, while the details are often pretty different, the general approach reveals many parallels. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research