From owner-cvs-all Thu Nov 14 8: 3: 3 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88BB037B401; Thu, 14 Nov 2002 08:03:02 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13C5743E77; Thu, 14 Nov 2002 08:03:01 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id DAA24444; Fri, 15 Nov 2002 03:02:48 +1100 Date: Fri, 15 Nov 2002 03:15:23 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Jake Burkholder Cc: Matt Jacob , , Subject: Re: cvs commit: src/sys/vm uma_dbg.c In-Reply-To: <20021110135825.B85338@locore.ca> Message-ID: <20021115030008.L10861-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 10 Nov 2002, Jake Burkholder wrote: > Apparently, On Sun, Nov 10, 2002 at 01:56:14PM -0500, > Jake Burkholder said words to the effect of; > > sparc64 can't do atomic operations on less than 32 bits, this needs > > a lock. > > fwiw this is in the man page: > > Certain architectures also provide operations for types smaller than > ``int''. > > char unsigned character > short unsigned short integer > 8 unsigned 8-bit integer > 16 unsigned 16-bit integer > > These must not be used in MI code because the instructions to implement > them efficiently may not be available. I think no arches should provide these and have removed them in my i386 version. They are (were) unused. I also want to remove atomic_*_long() on i386's. These are essentially useless on i386's with incorrectly sized longs (the default), since longs are essentially ints, but on i386's with 64-bit longs the current implementations just don't work. Correct implementations would need to use a lock, but this would defeat the main point of having atomic operations. atomic_*_long() are used mainly in drm and netgraph. atomic_t seems to be very bogus in drm. Some counters in drm and netgraph could reasonably be 64-bits, but longs don't give that on i386's and we have mostly avoided the issue of changing counters to uint64_t partly because making them atomic would be inefficient on 32-bit machine. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message