From owner-freebsd-smp Thu Dec 5 06:47:10 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA11078 for smp-outgoing; Thu, 5 Dec 1996 06:47:10 -0800 (PST) Received: from friley216.res.iastate.edu (friley216.res.iastate.edu [129.186.78.216]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id GAA11071 for ; Thu, 5 Dec 1996 06:47:06 -0800 (PST) Received: from friley216.res.iastate.edu (loopback [127.0.0.1]) by friley216.res.iastate.edu (8.8.3/8.7.3) with ESMTP id IAA04684; Thu, 5 Dec 1996 08:47:04 -0600 (CST) Message-Id: <199612051447.IAA04684@friley216.res.iastate.edu> X-Mailer: exmh version 1.6.9 8/22/96 To: Peter Wemm cc: smp@freebsd.org Subject: Re: make locking more generic? In-reply-to: Your message of Thu, 05 Dec 1996 17:25:01 +0800. <199612050925.RAA07355@spinner.DIALix.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Dec 1996 08:46:59 -0600 From: Chris Csanady Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Steve Passe wrote: >> Hi, >> >> >If any of you SMP guys have any words of wisdom, or documentation sources >> >for SMP technology, I would really like to hear from you with pointers. Al s > o, >> >> http://www.freebsd.org/~fsmp/SMP/books.html >> http://www.freebsd.org/~fsmp/SMP/threads.html >> -- >> Steve Passe | powered by >> smp@csn.net | FreeBSD > >There are also several "classes" of locks to consider. The version >that we use to guard the entry/exit points of the kernel allows recursion >and hence has a "nest count" which accounts for it's complexity and it's >impact on the task switch code. By recursion, I mean that a process >can enter the kernel lock, call something which ends up in copyin() >and takes another fault, which re-enters the kernel lock again. it needs >to keep track of how many times each process has entered the kernel so >that it can unwind it correctly. > >Then there's a simple boolean lock. It's a simple request/free lock >that does not care which cpu is in it at the time and does not allow >recursion. > >ENTRY(boot_lock) > /* This is the Intel reccomended semaphore method */ > movb $0xff, %al >2: > xchgb %al, bootlock /* xchg is implicitly locked */ > cmpb $0xff, %al > jz 2b > ret > >ENTRY(boot_unlock) > movb $0, %al > xchgb %al, bootlock /* xchg is implicitly locked */ > ret > > /* initial value is 0xff, or "busy" */ > .globl bootlock >bootlock: .byte 0xff > >Of course, there would be nothing stopping us using this simple lock >primative to protect a counting semaphore that allowed recursion and >didn't have to worry about atomic code. > >Then there's the 'lock ; bts ...' (bit test and set) and so on >instructions. > >4.4Lite2 has a lock 'manager' as well, that uses a simple lock to protect >the complex locking structures. There is a good description of how this >all fits together in a Lite2 context somewhere on the web. I think this >is on Steve's pages, if not I'll have to check my bookmarks. I dont think I have seen this there. Could you post the url? >There are other lock managers around, I believe Terry has mentioned >one or two tree-based managers as well - these can be used to >control the deadlock risks etc. Intention locking is one. There are a few good posts in the mail archives about that. It is also on freebsd-smp page as well.. >Having a single lock is nice and convenient at this stage of the game, >since we do not have to worry so much about kernel deadlocks while we >figure out the fundamental core functionality. (eg: APIC_IO, IPI's, >TLB sync, scheduling, starup/shutdown, idle loops, NCPU > 2 support etc) I wasn't referring to a fine grained implementation right off hand. Just a couple more locks, and it would be quite difficult to get into a deadlock situation with them. Even so, you could still call it giant locking.. :P Chris > >Cheers, >-Peter