tdb performance

[Stefan (metze) Metzmacher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

tridge at samba.org 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
 unused...

metze
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFFxuCJm70gjA5TCD8RAoK/AKCUIZyRT/pzcUVoox15xVi04AxlMQCgtawV
8QqpMQ/y9zEtt+NpPAUpnHo=
=6KXI
-----END PGP SIGNATURE-----