f_offset

[M. Warner Losh]

In message: <300DE361-167E-4491-8E8C-7A227225B506 at mac.com>
            Marcel Moolenaar <xcllnt at mac.com> 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.

Warner