tdb performance

tridge at tridge at
Sun Feb 4 23:49:51 GMT 2007


 > 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.

Cheers, Tridge

More information about the samba-technical mailing list