synchronization primitive size (was f_offset)

Jeff Roberson jroberson at jroberson.net
Thu Apr 17 13:26:28 UTC 2008


On Thu, 17 Apr 2008, Attilio Rao wrote:

> 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'.

I meant that they should be placed adjacent to each other so that neither 
one of them requires padding on 64bit machines.  Not that the flags and 
recurse should be within the same member.

>
> 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.

What do you think about witness operating as LOCK_PROFILING does now? 
Each lock would be looked up in a table to get the required information 
rather than embedding it in the datastructure.  This would solve the ABI 
issue.

>
> Thanks,
> Attilio
>
>
> -- 
> Peace can only be achieved by understanding - A. Einstein
>


More information about the freebsd-arch mailing list