From owner-freebsd-arch@FreeBSD.ORG Mon Apr 14 15:56:40 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 F2EE1106564A for ; Mon, 14 Apr 2008 15:56:40 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.80]) by mx1.freebsd.org (Postfix) with ESMTP id DC5458FC1E for ; Mon, 14 Apr 2008 15:56:40 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp005-s [10.150.69.68]) by smtpoutm.mac.com (Xserve/smtpout017/MantshX 4.0) with ESMTP id m3EFueIW019502; Mon, 14 Apr 2008 08:56:40 -0700 (PDT) Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp005/MantshX 4.0) with ESMTP id m3EFuS1k022548 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Apr 2008 08:56:34 -0700 (PDT) Message-Id: <300DE361-167E-4491-8E8C-7A227225B506@mac.com> From: Marcel Moolenaar To: Jeff Roberson In-Reply-To: <20080413222626.X959@desktop> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 14 Apr 2008 08:56:24 -0700 References: <20080412132457.W43186@desktop> <480313A2.4050306@nokia.com> <20080413222626.X959@desktop> X-Mailer: Apple Mail (2.919.2) 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 15:56:41 -0000 On Apr 14, 2008, at 1:27 AM, Jeff Roberson wrote: > > 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. I'm working on SMP for PowerPC.. -- Marcel Moolenaar xcllnt@mac.com