synchronization primitive size (was f_offset)

Jeff Roberson jroberson at jroberson.net
Thu Apr 17 03:27:45 UTC 2008


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.

For the !WITNESS case we need only the name pointer, the flags, recurse 
count, and actual lock uintptr_t.  This reduces the overhead to 3 pointers 
size on 64bit.

We could either conditionally compile WITNESS support, which has 
unpleasant side effects for binary modules, or use secondary storage with 
a hash similar to what I did with LOCK_PROFILING.

I think it's time to seriously consider this.

Thanks,
Jeff

>
> -- 
> John Baldwin
>


More information about the freebsd-arch mailing list