From owner-freebsd-smp Mon Jun 28 21:29:13 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id B41A71508D for ; Mon, 28 Jun 1999 21:29:11 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA26192; Mon, 28 Jun 1999 21:29:09 -0700 (PDT) (envelope-from dillon) Date: Mon, 28 Jun 1999 21:29:09 -0700 (PDT) From: Matthew Dillon Message-Id: <199906290429.VAA26192@apollo.backplane.com> To: Terry Lambert Cc: julian@whistle.com (Julian Elischer), peter@netplex.com.au, alc@cs.rice.edu, tlambert@primenet.com, bakul@torrentnet.com, freebsd-smp@freebsd.org Subject: Re: high-efficiency SMP locks - submission for review References: <199906290057.RAA07616@usr05.primenet.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> 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. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message