From owner-freebsd-arch@FreeBSD.ORG Mon Apr 14 17:32:34 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 7B3EB1065671 for ; Mon, 14 Apr 2008 17:32:34 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 3EF668FC0C for ; Mon, 14 Apr 2008 17:32:34 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.2/8.14.2) with ESMTP id m3EHZtsE049482; Mon, 14 Apr 2008 13:35:55 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.2/8.14.2/Submit) id m3EHZtp0049481; Mon, 14 Apr 2008 13:35:55 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Mon, 14 Apr 2008 13:35:55 -0400 From: David Schultz To: Jeff Roberson Message-ID: <20080414173555.GA49271@zim.MIT.EDU> Mail-Followup-To: Jeff Roberson , Arthur Hartwig , arch@FreeBSD.ORG References: <20080412132457.W43186@desktop> <480313A2.4050306@nokia.com> <20080413222626.X959@desktop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080413222626.X959@desktop> Cc: arch@FreeBSD.ORG, Arthur Hartwig Subject: Re: f_offset 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: Mon, 14 Apr 2008 17:32:34 -0000 On Sun, Apr 13, 2008, Jeff Roberson wrote: > Thanks. I hadn't seen that. Do you know which manual and section states > this? I was intending to simply use cmpxchg8b but it sounds like that may > not be necessary. We still have to handle other 32bit archs like powerpc > and mips but I'm not sure if any of those are SMP. Usually single-instruction writes to within a single cache line are atomic, and cache lines are often 128+ bits. The trouble is that 32-bit architectures may not have 64-bit store instructions at all. I know that 32-bit powerpc processors don't have 64-bit compare-and-swap atomic ops. They do have a stmw instruction, which is sort of equivalent to i386's 'rep stosd', and can store 64 bits in one instruction, but I doubt that that's atomic. Maybe the best strategy would be to say something like: #ifdef atomic_set_64 atomic_set_64(&fp->f_offset, uio_resid); #else mtx_lock(fp->f_mtx); fp->f_offset = uio_resid; #endif (Worse) alternatives: - Generic (very slow) atomic_set_64 implemented in terms of hashed mutexes. - Add a level of indirection to implement the 64-bit update in terms of atomic pointer ops, i.e.: newoffset = uio_resid; membar(); atomic_set_ptr(&fp->f_offsetp, &newoffset); The idea here is that pointer-size writes are often atomic even if uint64_t-size writes aren't.