From 11ab43084b10cf53b530cdc3a6036c898b79ca38 Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Sat, 14 Aug 2010 02:13:26 +0930 Subject: tdb: workaround starvation problem in locking entire database. We saw tdb_lockall() take 71 seconds under heavy load; this is because Linux (at least) doesn't prevent new small locks being obtained while we're waiting for a big log. The workaround is to do divide and conquer using non-blocking chainlocks: if we get down to a single chain we block. Using a simple test program where children did "hold lock for 100ms, sleep for 1 second" the time to do tdb_lockall() dropped signifiantly. There are ln(hashsize) locks taken in the contended case, but that's slow anyway. More analysis is given in my blog at http://rusty.ozlabs.org/?p=120 This may also help transactions, though in that case it's the initial read lock which uses this gradual locking routine; the update-to-write-lock code is separate and still tries to update in one go. Even though ABI doesn't change, minor version bumped so behavior change can be easily detected. Signed-off-by: Rusty Russell --- lib/tdb/wscript | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'lib/tdb/wscript') diff --git a/lib/tdb/wscript b/lib/tdb/wscript index a7afa98750..2fdd67f251 100644 --- a/lib/tdb/wscript +++ b/lib/tdb/wscript @@ -1,7 +1,7 @@ #!/usr/bin/env python APPNAME = 'tdb' -VERSION = '1.2.2' +VERSION = '1.2.3' blddir = 'bin' -- cgit