samba - Apr 2006 - Re: TDB locking overhead and performance...

On Sat, Apr 22, 2006 at 06:15:31PM +0100, Daniel J Blueman wrote:
 
> As a test, I changed the opening of the locking.tdb and brlock.tdb
> files to use the TDB_INTERNAL flag, avoiding use of the fcntl(F_SETLK)
> syscall for locking individual database records. Performance was a lot
> snappier, with quite a bit less system time used.
> 
> What is the scope of implementing shared memory TDBs, where locking
> could be done simply on structures?
How would you implement cross-process locking without
any syscalls? Maybe Linux has some fancy stuff here, but for
most unixes we need to coordinate the mmap'ed area for the
tdbs fcntl locks.

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.samba.org/archive/samba/attachments/20060422/041647e1/attachment.bin

Linux indeed hs some fancy locks for this, which were tested
with TDBs (see 
http://scholar.google.com/url?sa=U&q=http://www.realitydiluted.com/nptl-uclibc/docs/futex.pdf)
but there is no discussion of what happens when we lose a
process which is holding a mmap'd lock.  That was explicitly
not addressed in the paper, from the Ottawa Linux Symposium.
This may have been addressed by now, but I don't see any
references to it.

   Fcntl locks explicitly release if the locking process had
died, so deadlock isn't a big issue.  For that reason they're
preferred, even though they're far slower than spinlocks
on Solaris (that's a Solaris bug, by the way).

--dave



Volker Lendecke wrote:
> On Sat, Apr 22, 2006 at 06:15:31PM +0100, Daniel J Blueman wrote:
>  
> 
>>As a test, I changed the opening of the locking.tdb and brlock.tdb
>>files to use the TDB_INTERNAL flag, avoiding use of the fcntl(F_SETLK)
>>syscall for locking individual database records. Performance was a lot
>>snappier, with quite a bit less system time used.
>>
>>What is the scope of implementing shared memory TDBs, where locking
>>could be done simply on structures?
> 
> 
> How would you implement cross-process locking without
> any syscalls? Maybe Linux has some fancy stuff here, but for
> most unixes we need to coordinate the mmap'ed area for the
> tdbs fcntl locks.
> 
> Volker
-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net           |                      -- Mark Twain
(416) 223-5943

> > As a test, I changed the opening of the locking.tdb and brlock.tdb
> > files to use the TDB_INTERNAL flag, avoiding use of the fcntl(F_SETLK)
> > syscall for locking individual database records. Performance was a lot
> > snappier, with quite a bit less system time used.
> >
> > What is the scope of implementing shared memory TDBs, where locking
> > could be done simply on structures?
>
> How would you implement cross-process locking without
> any syscalls? Maybe Linux has some fancy stuff here, but for
> most unixes we need to coordinate the mmap'ed area for the
> tdbs fcntl locks.
Locking via a 'volatile int count' in a shared file-backed or
anonymous mapping, or via sys V shm is what I had in mind.

This would be quite clean to implement, but I just can't find any
user-space atomic operations exported by glibc. There are clever
tricks to use the kernel ones in /usr/include/asm/atomic.h, but that
is an ugly hack.

Any ideas?
--
Daniel J Blueman