Date: Wed, 16 Apr 2008 17:00:52 -1000 (HST) From: Jeff Roberson <jroberson@jroberson.net> To: John Baldwin <jhb@freebsd.org>, attilio@freebsd.org Cc: freebsd-arch@freebsd.org Subject: synchronization primitive size (was f_offset) Message-ID: <20080416165553.U959@desktop> In-Reply-To: <200804160930.27981.jhb@freebsd.org> References: <20080412132457.W43186@desktop> <200804160930.27981.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080416165553.U959>