fcntl spinlock in Linux?

[Jeff Layton]

On Thu, 24 Jan 2013 11:34:53 -0500
"J. Bruce Fields" <bfields at fieldses.org> wrote:

> On Thu, Jan 24, 2013 at 04:06:33PM +0100, Volker Lendecke wrote:
> > On Thu, Jan 24, 2013 at 02:05:00PM +0100, Stefan (metze) Metzmacher wrote:
> > > > If that interpretation is right, then I guess with many
> > > > cores in a NUMA configuration fcntl locks are just a VERY,
> > > > VERY bad idea at all if you want to scale.
> > > > 
> > > > Please tell me that I am wrong :-)
> > > 
> > > Reading through
> > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/DocBook/kernel-locking.tmpl
> > > indicates to me that this could be solved using RCU to protect the
> > > global lock list.
> > 
> > Follow-up question: The process shared robust mutexes, do
> > they scale better? Or do we also sit on a central spinlock
> > when we really start beating the futex API?
> > 
> > I can't imagine futex() spins on one central lock, but I
> > also could not imagine that fcntl does, so I would like to
> > know about bad surprises before we put much effort into
> > annihilate fcntl.
> 
> The problem you're seeing is definitely specific to fcntl. (And might
> not be that hard to fix, I'm not sure.  The biggest annoyance is
> probably the deadlock checking, but I doubt anyone depends on that--so
> perhaps we could do something like wait till there's been no progress
> for several seconds before kicking off the expensive deadlock check.)
> 
> --b.

Yep.

FWIW, all of that code used to be protected by the big kernel lock
(BKL). When that was finally ripped out recently, this spinlock is what
replaced it. It was really just a stopgap measure though and needs to
be broken up to use more granular locking.

As to when we'll get there -- who knows? I don't know of any immediate
plans to fix that up but maybe it's time to start looking at them...

Cheers,
-- 
Jeff Layton <jlayton at samba.org>