From owner-freebsd-arch@FreeBSD.ORG Mon Apr 14 08:27:22 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 5A7A51065674 for ; Mon, 14 Apr 2008 08:27:22 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.freebsd.org (Postfix) with ESMTP id 1E9908FC1A for ; Mon, 14 Apr 2008 08:27:22 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by py-out-1112.google.com with SMTP id u52so1974818pyb.10 for ; Mon, 14 Apr 2008 01:27:21 -0700 (PDT) Received: by 10.141.152.8 with SMTP id e8mr3198708rvo.19.1208161641074; Mon, 14 Apr 2008 01:27:21 -0700 (PDT) Received: from ?10.0.1.199? ( [24.94.72.120]) by mx.google.com with ESMTPS id g22sm9408758rvb.5.2008.04.14.01.27.19 (version=SSLv3 cipher=OTHER); Mon, 14 Apr 2008 01:27:20 -0700 (PDT) Date: Sun, 13 Apr 2008 22:27:46 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Arthur Hartwig In-Reply-To: <480313A2.4050306@nokia.com> Message-ID: <20080413222626.X959@desktop> References: <20080412132457.W43186@desktop> <480313A2.4050306@nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org 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 08:27:22 -0000 On Mon, 14 Apr 2008, Arthur Hartwig wrote: > ext Jeff Roberson wrote: >> So I'm in the midst of working on other filesystem concurrency issues and >> that has brought me back around to f_offset again. I'm working on a method >> to allow non-overlapping writes and reads to proceed concurrently to the >> same file. This means the exclusive vnode lock can not be used to protect >> f_offset even in the write case. >> >> To maintain the existing semantics I'm simply going to add an exclusive >> sx_xlock() around access to f_offset. This is done inconsistently today >> which is fine from the perspective of the updates in most cases being >> user-space races. However, f_offset is 64bit and can not be written >> atomically on 32bit systems and so requires some extra synchronization >> there. > I'm not sure of the processor family constraints of the i386 builds, but the > Intel IA32 architecture manual says reads and writes of a quadword (64 bits) > aligned on a quadword boundary are atomic (Pentium and newer CPUs). Guess > that leaves out i386, i486 (any others?) 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. Jeff