From owner-freebsd-smp Fri Jun 18 11:44:28 1999 Delivered-To: freebsd-smp@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id E647514F30 for ; Fri, 18 Jun 1999 11:44:22 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id LAA45043 for ; Fri, 18 Jun 1999 11:44:22 -0700 (PDT) Date: Fri, 18 Jun 1999 11:44:21 -0700 (PDT) From: Julian Elischer To: smp@freebsd.org Subject: Call to arms..-SMP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ok we've been working on improving some facets of FreeBSD's file IO however we are trailing Linux in this area, because they have recently managed to mode a number of important kernel modules out from under the Giant Lock (TM). Most noticable in this case are: 1/ File reads and writes for file data that is in memory (in the cache). Effectively they have the copyout() or uiomove (or whatever they use) drop the GKL so that more than one processor can do data moving at a time. 2/ In the Networking layer, they have changed things to allow more than one processor to do packet processing. BSDI have also done some of this. their approach has been very interesting: e.g. re: interrupts, They define a thread for each interrupt source (e.g. irq6,irg7, etc.) When the interrupt occurs they save regs and transfer to the stack associated with that thread. However all extra thread context switching is delayed (in the hope that it wont have to be done). If a lock is encountered, the rest of the context switch is done, and the thread sleeps. (and control is passed back to the holder of the lock (if they are runnable) or the original process. Lazy evaluation of the interrupt thread context switch.. very cunning.. Maybe something BDE could look at.. he's definitly the most qualified for that stuff. spls go away entirely after locks are ubiquitous. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message