fcntl spinlock in Linux?

[J. Bruce Fields]

On Wed, Jan 30, 2013 at 04:39:56PM +0100, Volker Lendecke wrote:
> On Wed, Jan 30, 2013 at 10:19:47AM -0500, J. Bruce Fields wrote:
> > On Wed, Jan 30, 2013 at 03:25:27PM +0100, Volker Lendecke wrote:
> > > On Wed, Jan 30, 2013 at 09:18:53AM -0500, J. Bruce Fields wrote:
> > > > On Wed, Jan 30, 2013 at 08:32:47AM +0100, Volker Lendecke wrote:
> > > > > On Tue, Jan 29, 2013 at 05:03:58PM -0500, J. Bruce Fields wrote:
> > > > > > On Tue, Jan 29, 2013 at 10:51:33PM +0100, Volker Lendecke wrote:
> > > > > > > On Tue, Jan 29, 2013 at 04:37:03PM -0500, J. Bruce Fields wrote:
> > > > > > > > It's probably also easiest to fix.
> > > > > > > 
> > > > > > > Including deadlock detection? I guess this would have to
> > > > > > > look at all locks held by a thread, possibly on different
> > > > > > > inodes.
> > > > > > 
> > > > > > As a way of at least testing whether this is your problem, we could rip
> > > > > > out the deadlock detection entirely.
> > > > > 
> > > > > Depending on the workload, this is partly Samba's problem.
> > > > > Some real-world workloads imposed upon Samba make thousands
> > > > > of smbds contend on a single lock.
> > > > 
> > > > By the way, do you have a way to boil any of these down into simple test
> > > > cases that we could use?  (If it didn't even require installing Samba
> > > > that would be ideal.)
> > > 
> > > I could send you a statically linked tdbtorture binary. It
> > > is very easy to run that into the problems we are seeing.
> > > Would that help?
> > 
> > Oh, well, if that's all it needs, I built tdbtorture here (just
> > ./configure && make from samba git on an F16 machine).  Hm, now what do
> > I do?:
> > 
> > 	# ./bin/tdbtorture -h
> > 	Usage: tdbtorture [-t] [-k] [-n NUM_PROCS] [-l NUM_LOOPS] [-s SEED] [-H HASH_SIZE]
> > 
> > Any recommended commandline, or any data you could share with expected
> > vs. actual results?
> 
> TDB_NO_FSYNC=1 time bin/tdbtorture -n 5000
> 
> and the load goes through the roof. Your mileage may vary
> depending on your machine, number of cpus etc. As this is
> essentially 5000 processes marching one behind another on
> two hash chains, the ideal result would be something like 2
> or so.

Thanks!

May be a while before anyone gets to it, but it's definitely something
we can and should fix.

--b.