From owner-freebsd-arch@FreeBSD.ORG Sun Mar 16 13:46:44 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A79F106564A for ; Sun, 16 Mar 2008 13:46:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by mx1.freebsd.org (Postfix) with ESMTP id DCDA88FC28 for ; Sun, 16 Mar 2008 13:46:43 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m2GDkNnR019701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 00:46:25 +1100 Date: Mon, 17 Mar 2008 00:45:12 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Jeff Roberson In-Reply-To: <20080315201153.X910@desktop> Message-ID: <20080317003655.A40697@besplex.bde.org> References: <20080315195328.V910@desktop> <20080315201153.X910@desktop> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kip Macy , arch@freebsd.org Subject: Re: separating out memory checks from INVARIANTS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2008 13:46:44 -0000 On Sat, 15 Mar 2008, Jeff Roberson wrote: > On Sat, 15 Mar 2008, Kip Macy wrote: >> Would it make it possible to do memory allocation without holding a >> lock in the M_NOWAIT case? > > Yes, when I originally wrote the code it didn't require a lock because I > relied on byte writes being atomic. However, we had platforms for which that > wasn't true. (alpha). It may be that it's safe not to lock even now on > x86/amd64. I don't know the specifics of the memory architectures on > powerpc, arm, mips, etc. though. sparc64 only supports atomic ops on sizes 32 and 64 bits. I think it and not alpha was responsible for eliminating use of 8 and 16 bit atomic ops in MI code. My version of atomic.h for i386 only supports atomic ops on size 32. 8 and 16 bit atomic ops are not usable in MI code and are or were not used in i386 MD code, so they are just interface bloat. Bruce