synchronization primitive size (was f_offset)
attilio at freebsd.org
Thu Apr 17 12:25:15 UTC 2008
2008/4/17, Jeff Roberson <jroberson at jroberson.net>:
> On Wed, 16 Apr 2008, John Baldwin wrote:
> > On Saturday 12 April 2008 07:51:15 pm Jeff Roberson wrote:
> > > The sx lock will nearly double the size of struct file. Although it's
> > > lost some weight in 8.0 that is quite unfortunate. However, the method
> > > using LOCKED & WAITING flags, msleep and a mutex has ruined performance
> > > too many cases to continue using it.
> > >
> > You could use a pool of sx locks and hash the file pointer to get an
> > (ala the mtx pools) to avoid bloating struct file if desired.
> This would not be a good idea since the sx is held over actual io. Any
> collisions would mean blocking unrelated files/vnodes.
> I think we should use the right synchronization primitive for the job. If
> people are upset at how much space overhead that adds we need to rethink how
> big our synchronization primitives are.
> If we move the *_recurse fields into lock object they can buddy up with
> lo_flags potentially saving 8 bytes of pading waste on 64bit architectures.
it is not possible.
Lower 16 bits of lo_flags are currently used for special flags,
external flags, by sx and lockmgr and they are intented to be
Btw, I worked some in this week-end about this issue.
I just broke lock_object into for WITNESS (moving there lo_type and
lod_* fields), I embedded the recursion counter in the lockmgr
structure and statically sized lo_flags and lo_recurse to 32 bits. For
the !WITNESS case the size of lock_object was 2/3 and for locking
primitives 1/2. It requires, however, ABI breakage for WITNESS which
is something we don't want really.
Peace can only be achieved by understanding - A. Einstein
More information about the freebsd-arch