tdb performance

Stefan (metze) Metzmacher metze at
Mon Feb 5 07:45:14 GMT 2007

Hash: SHA1

tridge at schrieb:
> Volker,
>  > Hmmmm. Can't tdb_free() consider these records as ones to
>  > merge if they happen to be next to a record to be deleted?
> Aren't you planning to only record the location of these records in
> memory, not in the tdb? (or perhaps I misunderstood your proposal).
> If so, then the problem would be if the process exits while there are
> some of these pending. Then we'd only find them with a traverse.
> A completely different approach would be to add support for futxes as
> an alternative to fcntl locks in tdb. A futex has essentially zero
> cost in the uncontended case (no system calls), and is just as
> efficient as blocking fcntl locks in the contended case (no spinning
> like our old spinlock code used). So futexes are pretty much ideal,
> except that:
>  1) it's a tricky and subtle API
>  2) it's very linux specific
> We should also revive the proposal for a hash of freelists at some
> stage. That would make a big difference for some loads. The idea is to
> have N freelists (maybe 8 or so as default), plus a master freelist
> that the other freelists feed off when empty. We'd hash on pid (or
> similar id) to choose the freelist.

with futexes it would also be possible to use epoll to wait to get the
lock, but the FUTEX_FD feature will be removed from linux as it's mostly

Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE -


More information about the samba-technical mailing list