From owner-freebsd-arch@FreeBSD.ORG Thu Apr 17 03:02:02 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 1441B1065683 for ; Thu, 17 Apr 2008 03:02:02 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.227]) by mx1.freebsd.org (Postfix) with ESMTP id C18F78FC19 for ; Thu, 17 Apr 2008 03:02:01 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by wr-out-0506.google.com with SMTP id 50so16354wra.13 for ; Wed, 16 Apr 2008 20:02:00 -0700 (PDT) Received: by 10.142.48.14 with SMTP id v14mr248420wfv.133.1208401319958; Wed, 16 Apr 2008 20:01:59 -0700 (PDT) Received: from ?10.0.1.199? ( [24.94.72.120]) by mx.google.com with ESMTPS id 27sm18263071wfa.0.2008.04.16.20.01.57 (version=SSLv3 cipher=OTHER); Wed, 16 Apr 2008 20:01:58 -0700 (PDT) Date: Wed, 16 Apr 2008 17:02:37 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: "M. Warner Losh" In-Reply-To: <20080416.093827.-262812665.imp@bsdimp.com> Message-ID: <20080416170104.G959@desktop> References: <480313A2.4050306@nokia.com> <20080413222626.X959@desktop> <300DE361-167E-4491-8E8C-7A227225B506@mac.com> <20080416.093827.-262812665.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, xcllnt@mac.com, Arthur.Hartwig@nokia.com 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: Thu, 17 Apr 2008 03:02:02 -0000 On Wed, 16 Apr 2008, M. Warner Losh wrote: > In message: <300DE361-167E-4491-8E8C-7A227225B506@mac.com> > Marcel Moolenaar writes: > : > : 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.. > > Support for MIPS SMP is in the initial commit. It might not be > working, but one of the big reasons that people want MIPS and FreeBSD > is due to the excellent scaling work that's been done as well as the > prevenance of multicore MIPS designs for certain application domains. My intent is to support 32bit platforms with a generic shim that grabs a mtx pool lock to provide atomic like primitives for 64bit. I think that will sufficiently solve the issue. For 32bit non-smp we could simply disable interrupts during the operation. > > Warner >