From owner-freebsd-smp Thu Jul 17 14:09:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA05025 for smp-outgoing; Thu, 17 Jul 1997 14:09:46 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA04988; Thu, 17 Jul 1997 14:09:05 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id PAA15231; Thu, 17 Jul 1997 15:08:46 -0600 (MDT) Message-Id: <199707172108.PAA15231@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Poul-Henning Kamp cc: smp@freebsd.org, Peter Wemm , dyson@freebsd.org Subject: Re: pushdown of "giant lock" In-reply-to: Your message of "Thu, 17 Jul 1997 22:27:40 +0200." <18580.869171260@critter.dk.tfs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Jul 1997 15:08:46 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > >DESIGN PROPOSAL: > > ... > As the guy who's done it before and in this case did it last time, let > me add some other input to this topic: > > 1. Add a optional (possibly compile-option) circular buffer which will > record the lock actions. somewher I have debug code for the lock that uses an XXX-kbyte buffer of INTs to record each lock transition, allowing you to record the last XXX,000 transitions if you wish. I also built a tool to scarf this buffer and present it in a nice formatted fashon. It was quite useful for getting the XXPRESS system working (first >2 CPU system to work properly). --- > 2. Add a permanent version of the ugly serial-port stuff, under a compile- > time option of course, to record the lock actions. the above tool eliminates the need for this, it sucks the buffer via /dev/kmem. --- > 3. Consider redesigning the lock implementation for the purpose, rather > that try to modify the rather special lock we have now... eventually we will diverge in many different locks/primatives for specific purposes. my proposal is just for the 1st step on that path. I envision each of the 3 classes I mentioned to develop their own unique form. I do think the modified version I outlined should serve well as a start, but I am also open to suggestions for alternate algorithms. thanx for the input, lets get some more discussion of this so I can get started with the code! -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD