synchronization primitive size (was f_offset)

[Attilio Rao]

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
> of
> > > using LOCKED & WAITING flags, msleep and a mutex has ruined performance
> in
> > > too many cases to continue using it.
> > >
> >
> > You could use a pool of sx locks and hash the file pointer to get an
> offset
> > (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
'reserved'.

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.

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein