Re: FILEDESC_LOCK() implementation

On Wednesday 21 June 2006 18:00, Robert Watson wrote:
> 
> On Wed, 21 Jun 2006, John Baldwin wrote:
> 
> >> The problem is this: when you have threads in the same process, file 
> >> descriptor lookup is performed against a common file descriptor array. 
> >> That array is protected by a lock, the filedesc lock.  When lots of
> >> threads simultaneously perform file descriptor operations, they contend
> >> on the file descriptor array lock.  So if you have 30 threads all doing
> >> I/O, they are constantly looking up file descriptors and bumping into
> >> each other.  This is particularly noticeable for network workloads, where
> >> many operations are very fast, and so they occur in significant quantity. 
> >> The M:N threading library actually handles this quite well by bounding
> >> the number of threads trying to acquire the lock to the number of
> >> processors, but with libthr you get pretty bad performance.  This
> >> contention problem also affects MySQL, etc.
> >>
> >> You can imagine a number of ways to work on this, but it's a tricky
> >> problem that has to be looked at carefully.
> >
> > Are the lookup operations using a shared lock so that only things like
> > open and close would actually contend?
> 
> I'm not sure anyone has tried that.  The semantics of the filedesc lock seem
> a bit complicated, I don't remember why that is right now.

It used to be an sx lock and it was converted to the current "thing" because 
sx locks were too slow.  I'd rather expend the effort on changing sx locks to 
use the same atomic ops as rwlocks (and use sleepq(9) directly rather than 
cv(9)) at which point we can probably just make it an sx lock again and use 
slock's for things like fget().

-- 
John Baldwin