From owner-freebsd-smp Mon Jun 28 23:40:50 1999 Delivered-To: freebsd-smp@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id A9C19151C4 for ; Mon, 28 Jun 1999 23:40:22 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 660BE82; Tue, 29 Jun 1999 14:40:11 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Matthew Dillon Cc: Terry Lambert , julian@whistle.com (Julian Elischer), alc@cs.rice.edu, bakul@torrentnet.com, freebsd-smp@freebsd.org Subject: Re: high-efficiency SMP locks - submission for review In-reply-to: Your message of "Mon, 28 Jun 1999 21:29:09 MST." <199906290429.VAA26192@apollo.backplane.com> Date: Tue, 29 Jun 1999 14:40:11 +0800 From: Peter Wemm Message-Id: <19990629064011.660BE82@overcee.netplex.com.au> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Dillon wrote: > > :> and in UP those locks that need atomicity would be optimised away. > :> > :> We WILL need locking in UP when we move to kernel threads, but that > :> doesn't require bus atomicity. > : > :No one is currently bothering with anything but the Intel MESI > :coherency model for SMP, anyway, so I don't understand the > :relevence of bus coherency to the argument. > : > :My only point is that the code needs to degrade gracefully (e.g. > :without rebuilding your kernel with a magic doohickey flipped on > :or off for no obvious reason). > : > : Terry Lambert > : terry@lambert.org > > I'm pretty sure that we need bus coherency for general RMW instructions > such as add, and, or, etc... Any given cpu will not take an interrupt > in the middle of an instruction, but in an SMP environment I do not > believe those instructions use indivisible cache-coherent bus cycles. > Thus the assembly lock prefix is necesary. I am not absolutely sure of > that, but I believe that to be the case for Intel. As I understand it, an Intel cpu won't take an interrupt except on an instruction boundary and the same goes for traps. However, I have memories of other cpus that could (I think) take faults mid-instruction etc. (68k family for example) Under SMP, you are correct. You have to do an explicit lock prefix to get an atomic read-modify-write cycle that no other cpu or bus master will interfere with. Some instructions are implicitly locked, xchg for example, and cannot have a lock prefix. (Remember the F00F bug anyone?) So, yes, you must do a 'lock; addl ....' etc if you want it to be coherent under SMP. > -Matt > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > > Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message