svn commit: samba r9769 - in branches/SAMBA_4_0: . source/lib/tdb/common

tridge at samba.org tridge at samba.org
Tue Aug 30 00:36:13 GMT 2005


Author: tridge
Date: 2005-08-30 00:36:12 +0000 (Tue, 30 Aug 2005)
New Revision: 9769

WebSVN: http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&root=samba&rev=9769

Log:
 r11592 at blu:  tridge | 2005-08-30 10:40:19 +1000
 added a tdb optimisation that speeds up non-indexed ldb by a large
 margin (often 10x or more). I'd be interested in any comments on the
 safety of this optimisation. See the comment in the code for an
 explanation.
 

Modified:
   branches/SAMBA_4_0/
   branches/SAMBA_4_0/source/lib/tdb/common/tdb.c


Changeset:

Property changes on: branches/SAMBA_4_0
___________________________________________________________________
Name: svk:merge
   - a953eb74-4aff-0310-a63c-855d20285ebb:/local/samba4:11080
   + a953eb74-4aff-0310-a63c-855d20285ebb:/local/samba4:11592

Modified: branches/SAMBA_4_0/source/lib/tdb/common/tdb.c
===================================================================
--- branches/SAMBA_4_0/source/lib/tdb/common/tdb.c	2005-08-30 00:26:44 UTC (rev 9768)
+++ branches/SAMBA_4_0/source/lib/tdb/common/tdb.c	2005-08-30 00:36:12 UTC (rev 9769)
@@ -1250,6 +1250,43 @@
 
 	/* Lock each chain from the start one. */
 	for (; tlock->hash < tdb->header.hash_size; tlock->hash++) {
+
+		/* this is an optimisation for the common case where
+		   the hash chain is empty, which is particularly
+		   common for the use of tdb with ldb, where large
+		   hashes are used. In that case we spend most of our
+		   time in tdb_brlock(), locking empty hash chains.
+
+		   To avoid this, we do an unlocked pre-check to see
+		   if the hash chain is empty before starting to look
+		   inside it. If it is empty then we can avoid that
+		   hash chain. If it isn't empty then we can't believe
+		   the value we get back, as we read it without a
+		   lock, so instead we get the lock and re-fetch the
+		   value below.
+
+		   Notice that not doing this optimisation on the
+		   first hash chain is critical. We must guarantee
+		   that we have done at least one fcntl lock at the
+		   start of a search to guarantee that memory is
+		   coherent on SMP systems. If records are added by
+		   others during the search then thats OK, and we
+		   could possibly miss those with this trick, but we
+		   could miss them anyway without this trick, so the
+		   semantics don't change.
+
+		   With a non-indexed ldb search this trick gains us a
+		   factor of more than 10 in speed on a linux 2.6.x
+		   system.
+		 */
+		if (!tlock->off && tlock->hash != 0) {
+			u32 off;
+			if (ofs_read(tdb, TDB_HASH_TOP(tlock->hash), &off) == 0 &&
+			    off == 0) {
+				continue;
+			}
+		}
+
 		if (tdb_lock(tdb, tlock->hash, F_WRLCK) == -1)
 			return -1;
 



More information about the samba-cvs mailing list