idtree: fix overflow for v. large ids on allocation and removal

Chris Cowan tracked down a SEGV in sub_alloc: idp->level can actually
be equal to 7 (MAX_LEVEL) there, as it can be in sub_remove.

idtree: fix right shift of signed ints

(Imported from SAMBA commit 2db1987f5a3a)

Right-shifting signed integers in undefined; indeed it seems that on
AIX with their compiler, doing a 30-bit shift on (INT_MAX-200) gives
0, not 1 as we might expect (THIS WAS WRONG, REAL FIX LATER).

The obvious fix is to make id and oid unsigned: l (level count) is also
logically unsigned.

(Note: Samba doesn't generally get to ids > 1 billion, but ctdb does)

Reported-by: Chris Cowan <cc@us.ibm.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

idtree: import fix from SAMBA source

(Imported from b53f8c187de8)

Author: Rusty Russell <rusty@rustorp.com.au>
Date:   Thu Jun 10 13:27:51 2010 -0700

Since idtree assigns sequentially, it rarely reaches high numbers.
But such numbers can be forced with idr_get_new_above(), and that
reveals two bugs:

1) Crash in sub_remove() caused by pa array being too short.
2) Shift by more than 32 in _idr_find(), which is undefined, causing
   the "outside the current tree" optimization to misfire and return NULL.

idtree: add unit test for ids around INT_MAX

This causes a SEGV on my laptop.

ccanlint: ignore comments when parsing examples.

We insert comments when we massage or combine examples; don't let these
throw off our analysis (as happened for idtree.h).

ccanlint: show example we actually compiled when we report warnings.

ccanlint: examples_compile depends on build, which depends on build_objs

We might as well use the compiled .o rather than all the little .o files.

ccanlint: fix usage of static funcs

Out-by-one error had us using character prior to declaration, eg, in
"static int *foo" we use "*foo".  This seems to compile, but is weird.

array: fix type introduced in handling !HAVE_TYPEOF

Commit da72623aec30 added a typo; ccanlint caught it, but doesn't consider
test compile failing to be fatal (it should!).

Merge branch 'tdb2'

tdb2: update documentation

Specifically the linked free tables, and reflect on the status of each
point of the design document.

tdb2: use separate magic constants for chain, htable and ftable entries

Rather than overloading TDB_USED_MAGIC and the hash value as we do now.
We also rename "free list" to the more-accurate "free table" everywhere.

tdb2: direct access during transactions.

Currently we fall back to copying data during a transaction, but we don't
need to in many cases.  Grant direct access in those cases.

Before:
$ ./speed --transaction 1000000
Adding 1000000 records:  2409 ns (59916680 bytes)
Finding 1000000 records:  1156 ns (59916680 bytes)
Missing 1000000 records:  604 ns (59916680 bytes)
Missing 1000000 records:  604 ns (59916680 bytes)
Traversing 1000000 records:  1226 ns (59916680 bytes)
Deleting 1000000 records:  1556 ns (119361928 bytes)
Re-adding 1000000 records:  2326 ns (119361928 bytes)
Appending 1000000 records:  3269 ns (246656880 bytes)
Churning 1000000 records:  5613 ns (338235248 bytes)

After:
$ ./speed --transaction 1000000
Adding 1000000 records:  1902 ns (59916680 bytes)
Finding 1000000 records:  1032 ns (59916680 bytes)
Missing 1000000 records:  606 ns (59916680 bytes)
Missing 1000000 records:  606 ns (59916680 bytes)
Traversing 1000000 records:  741 ns (59916680 bytes)
Deleting 1000000 records:  1347 ns (119361928 bytes)
Re-adding 1000000 records:  1727 ns (119361928 bytes)
Appending 1000000 records:  2561 ns (246656880 bytes)
Churning 1000000 records:  4403 ns (338235248 bytes)

tdb2: add write flag to tdb_direct

This is a precursor to direct access during transactions: they care about
whether we are going to read or write to the file.

tdb2: hash chaining

If we get enough hash collisions, we can run out of hash bits; this almost
certainly is caused by a deliberate attempt to break the tdb (hash bombing).

Implement chained records for this case; they're slow but will keep the
rest of the database functioning.

tdb2: use magic freetable value rather than different magic for coalescing

We have to unlock during coalescing, so we mark records specially to indicate
to tdb_check that they're not on any list, and to prevent other coalescers
from grabbing them.

Use a special free list number, rather than a new magic.

tdb2: compare the extra 11 hash bits in the header.

We already have 10 hash bits encoded in the offset itself; we only get
here incorrectly about 1 time in 1000, so it's a pretty minor
optimization at best.

Nonetheless, we have the information, so let's check it before
accessing the key.  This reduces the probability of a false keycmp by
another factor of 2000.

tdb2: add comparison stats

tdb2: clean up logging

Logged errors should always set tdb->ecode before they are called, and
there's little reason to have a sprintf-style logging function since
we can do the formatting internally.

Change the tdb_log attribute to just take a "const char *", and create
a new tdb_logerr() helper which sets ecode and calls it.  As a bonus,
mark it COLD so the compiler can optimize appropriately knowing that
it's unlikely to be invoked.

tdb2: remove truncated bit.

There was an idea that we would use a bit to indicate that we didn't have
the full hash value; this would allow us to move records down when we
expanded a hash without rehashing them.

There's little evidence that rehashing in this case is particularly
expensive, so remove the bit.  We use that bit simply to indicate that
an offset refers to a subhash instead.

tdb2: use direct access for tdb_read_off/tdb_write_off

This is one case where getting rid of tdb_get() cost us.  Also, we
add more read-only checks.

Before we removed tdb_get:
Adding 1000000 records:  6480 ns (59900296 bytes)
Finding 1000000 records:  2839 ns (59900296 bytes)
Missing 1000000 records:  2485 ns (59900296 bytes)
Traversing 1000000 records:  2598 ns (59900296 bytes)
Deleting 1000000 records:  5342 ns (59900296 bytes)
Re-adding 1000000 records:  5613 ns (59900296 bytes)
Appending 1000000 records:  12194 ns (93594224 bytes)
Churning 1000000 records:  14549 ns (93594224 bytes)

Now:
Adding 1000000 records:  6307 ns (59900296 bytes)
Finding 1000000 records:  2801 ns (59900296 bytes)
Missing 1000000 records:  2515 ns (59900296 bytes)
Traversing 1000000 records:  2579 ns (59900296 bytes)
Deleting 1000000 records:  5225 ns (59900296 bytes)
Re-adding 1000000 records:  5878 ns (59900296 bytes)
Appending 1000000 records:  12665 ns (93594224 bytes)
Churning 1000000 records:  16090 ns (93594224 bytes)

tdb2: remove tdb_get()

We have four internal helpers for reading data from the database:
1) tdb_read_convert() - read (and convert) into a buffer.
2) tdb_read_off() - read (and convert) and offset.
3) tdb_access_read() - malloc or direct access to the database.
4) tdb_get() - copy into a buffer or direct access to the database.

The last one doesn't really buy us anything, so remove it (except for
tdb_read_off/tdb_write_off, see next patch).

Before:
Adding 1000000 records:  6480 ns (59900296 bytes)
Finding 1000000 records:  2839 ns (59900296 bytes)
Missing 1000000 records:  2485 ns (59900296 bytes)
Traversing 1000000 records:  2598 ns (59900296 bytes)
Deleting 1000000 records:  5342 ns (59900296 bytes)
Re-adding 1000000 records:  5613 ns (59900296 bytes)
Appending 1000000 records:  12194 ns (93594224 bytes)
Churning 1000000 records:  14549 ns (93594224 bytes)

After:
Adding 1000000 records:  6497 ns (59900296 bytes)
Finding 1000000 records:  2854 ns (59900296 bytes)
Missing 1000000 records:  2563 ns (59900296 bytes)
Traversing 1000000 records:  2735 ns (59900296 bytes)
Deleting 1000000 records:  11357 ns (59900296 bytes)
Re-adding 1000000 records:  8145 ns (59900296 bytes)
Appending 1000000 records:  10939 ns (93594224 bytes)
Churning 1000000 records:  18479 ns (93594224 bytes)

ccanlint: build depends if necessary

Now it will build copies of other ccan deps if it can't find them.

tdb2: trivial optimization for free list

We currently only have one, so shortcut the case where we want our current
one.

tdb2: Add stats attribute.

This is good for deep debugging.

tdb2: enable transactions in tdbtorture

tdb2: stricter ordering on expansion lock

It's problematic for transaction commit to get the expansion lock, but
in fact we always grab a hash lock before the transaction lock, so it
doesn't really need it (the transaction locks the entire database).

Assert that this is true, and fix up a few lowlevel tests where it wasn't.

tdb2: remove all the dead code

I left much tdb1 code in various files for inspiration, and in case I needed
it later.  Now we have all the major features implemented, remove it.

tdb2: transaction support

This adds transactions to tdb2; the code is taken from tdb1 with minimal
modifications, as are the unit

tdb2: allow nesting of read locks on top of write locks.

If we have a write lock and ask for a read lock, that's OK, but not the
other way around.  tdb_nest_lock() allowed both, tdb_allrecord_lock() allowed
neither.

ccanlint: fix -x core dump

This wasn't fixed when we converted to ccan/opt in 8d70667887.

Unfortunately, unistd.h defines optarg, so the compiler didn't catch
this.

tdb2: relax locking to allow two free list locks at once

As long as they are in descending order.  This prevents the common case of:

1) Grab lock for bucket.
2) Remove entry from bucket.
3) Drop lock for bucket.
4) Grab lock for bucket for leftover.
5) Add leftover entry to bucket.
6) Drop lock for leftover bucket.

In particular it's quite common for the leftover bucket to be the same
as the entry bucket (when it's the largest bucket); if it's not, we are
no worse than before.

Current results of speed test:
$ ./speed 1000000
Adding 1000000 records:  13194 ns (60083192 bytes)
Finding 1000000 records:  2438 ns (60083192 bytes)
Traversing 1000000 records:  2167 ns (60083192 bytes)
Deleting 1000000 records:  9265 ns (60083192 bytes)
Re-adding 1000000 records:  10241 ns (60083192 bytes)
Appending 1000000 records:  17692 ns (93879992 bytes)
Churning 1000000 records:  26077 ns (93879992 bytes)

Previous:
$ ./speed 1000000
Adding 1000000 records:  23210 ns (59193360 bytes)
Finding 1000000 records:  2387 ns (59193360 bytes)
Traversing 1000000 records:  2150 ns (59193360 bytes)
Deleting 1000000 records:  13392 ns (59193360 bytes)
Re-adding 1000000 records:  11546 ns (59193360 bytes)
Appending 1000000 records:  29327 ns (91193360 bytes)
Churning 1000000 records:  33026 ns (91193360 bytes)

tdb2: use expansion heuristics from tdb1

This reduces the amount of expansion we do.

Before:
./speed 1000000
Adding 1000000 records:  23210 ns (59193360 bytes)
Finding 1000000 records:  2387 ns (59193360 bytes)
Traversing 1000000 records:  2150 ns (59193360 bytes)
Deleting 1000000 records:  13392 ns (59193360 bytes)
Re-adding 1000000 records:  11546 ns (59193360 bytes)
Appending 1000000 records:  29327 ns (91193360 bytes)
Churning 1000000 records:  33026 ns (91193360 bytes)

After:
$ ./speed 1000000
Adding 1000000 records:  17480 ns (61472904 bytes)
Finding 1000000 records:  2431 ns (61472904 bytes)
Traversing 1000000 records:  2194 ns (61472904 bytes)
Deleting 1000000 records:  10948 ns (61472904 bytes)
Re-adding 1000000 records:  11247 ns (61472904 bytes)
Appending 1000000 records:  21826 ns (96051424 bytes)
Churning 1000000 records:  27242 ns (96051424 bytes)

tdb2: shrink free header from 32 to 24 bytes.

This reduces our minimum key+data length to 8 bytes; we do this by packing
the prev pointer where we used to put the flist pointer, and storing the
flist as an 8 bit index (meaning we can only have 256 free tables).

Note that this has a perverse result on the size of the database, as our
4-byte key and 4-byte data now fit perfectly in a minimal record, so
appeding causes us to allocate new records which are 50% larger,
since we detect growing.

Current results of speed test:
$ ./speed 1000000
Adding 1000000 records:  23210 ns (59193360 bytes)
Finding 1000000 records:  2387 ns (59193360 bytes)
Traversing 1000000 records:  2150 ns (59193360 bytes)
Deleting 1000000 records:  13392 ns (59193360 bytes)
Re-adding 1000000 records:  11546 ns (59193360 bytes)
Appending 1000000 records:  29327 ns (91193360 bytes)
Churning 1000000 records:  33026 ns (91193360 bytes)

Previous:
$ ./speed 1000000
Adding 1000000 records:  28324 ns (67232528 bytes)
Finding 1000000 records:  2468 ns (67232528 bytes)
Traversing 1000000 records:  2200 ns (67232528 bytes)
Deleting 1000000 records:  13083 ns (67232528 bytes)
Re-adding 1000000 records:  16433 ns (67232528 bytes)
Appending 1000000 records:  2511 ns (67232528 bytes)
Churning 1000000 records:  31068 ns (67570448 bytes)

tdb2: rename set_header to the more appropriate set_used_header.

tdb2: Add speed test to tdb and tdb2

Current results of speed test:
$ ./speed 1000000
Adding 1000000 records:  14726 ns (67244816 bytes)
Finding 1000000 records:  2844 ns (67244816 bytes)
Missing 1000000 records:  2528 ns (67244816 bytes)
Traversing 1000000 records:  2572 ns (67244816 bytes)
Deleting 1000000 records:  5358 ns (67244816 bytes)
Re-adding 1000000 records:  9176 ns (67244816 bytes)
Appending 1000000 records:  3035 ns (67244816 bytes)
Churning 1000000 records:  18139 ns (67565840 bytes)
$ ./speed 100000
Adding 100000 records:  13270 ns (14349584 bytes)
Finding 100000 records:  2769 ns (14349584 bytes)
Missing 100000 records:  2422 ns (14349584 bytes)
Traversing 100000 records:  2595 ns (14349584 bytes)
Deleting 100000 records:  5331 ns (14349584 bytes)
Re-adding 100000 records:  5875 ns (14349584 bytes)
Appending 100000 records:  2751 ns (14349584 bytes)
Churning 100000 records:  20666 ns (25771280 bytes)

vs tdb1 (with hashsize 100003):
$ ./speed 1000000
Adding 1000000 records:  8547 ns (44306432 bytes)
Finding 1000000 records:  5595 ns (44306432 bytes)
Missing 1000000 records:  3469 ns (44306432 bytes)
Traversing 1000000 records:  4571 ns (44306432 bytes)
Deleting 1000000 records:  12115 ns (44306432 bytes)
Re-adding 1000000 records:  10505 ns (44306432 bytes)
Appending 1000000 records:  10610 ns (44306432 bytes)
Churning 1000000 records:  28697 ns (44306432 bytes)
$ ./speed 100000
Adding 100000 records:  6030 ns (4751360 bytes)
Finding 100000 records:  3141 ns (4751360 bytes)
Missing 100000 records:  3143 ns (4751360 bytes)
Traversing 100000 records:  4659 ns (4751360 bytes)
Deleting 100000 records:  7891 ns (4751360 bytes)
Re-adding 100000 records:  5913 ns (4751360 bytes)
Appending 100000 records:  4242 ns (4751360 bytes)
Churning 100000 records:  15300 ns (4751360 bytes)

tdb2: fix tdb_check() return when free table entries missing.

It mistakenly returned -1 meaning "success".

tdb2: make tdb_check call check() function.

tdb2: make summary command handle recovery "dead zone"

We can run summary with a recovery area, or a dead zone.

tdb2: cancel transactions on tdb_close

Otherwise we leak memory.

tdb2: handle chains of free tables

This adds chains of free tables: we choose one at random at the start and
we iterate through them when they are exhausted.

Currently there is no code to actually add a new free table, but we test
that we can handle it if we add one in future.

tdb2: get rid of zones

Zones were a bad idea.  They mean we can't simply add stuff to the end
of the file (which transactions relied upon), and there's no good heuristic
in how to size them.

This patch reverts us to a single free table.

tdb2: fix bucket search

We were previously jumping straight from the first bucket to the end.

tdb2: only adjust size once when growing

We were adding 50% to datalen twice, so move it out of adjust_size and
make the callers do it.

We also add a test that the heuristic is working at all.

tdb2: remove tailer

We don't actually need it.

tdb2: fix tdb_chainlock

We can't enlarge the lock without risking deadlock, so tdb_chainlock() can't
simply grab a one-byte lock; it needs to grab the lock we'd need to protect
the hash.

In theory, tdb_chainlock_read() could use a one-byte lock though.

tdb2: fix coalesce race #3

When we're coalescing, we need to drop the lock on the current free list, as
we've enlarged the block and it may now belong in a different list.

Unfortunately (as shown by repeated tdbtorture -n 8) another coalescing run
can do the coalescing while we've dropped the lock.  So for this case, we
use the TDB_COALESCING_MAGIC flag so it doesn't look free.

tdb2: add TDB_COALESCING_MAGIC to solve coalescing race.

A new special record marker to indicate coalescing is in progress.

tdb2: fix coalesce race #2

When we find a free block, we need to mark it as used before we drop the
free lock, even though we've removed it from the list.  Otherwise the
coalescing code can find it.

This means handing the information we need down to lock_and_alloc, which
also means we know when we're grabbing a "growing" entry, and can relax
the heuristics about finding a good-sized block in that case.

tdb2: coalescing race fix #1

When coalescing, we check the adjacent entry then lock its free list: we
need to *recheck* after locking, to make sure it's still in that free list.

tdb2: minor optimization for set_header

We actually only need the bottom 5 bits of the hash value, so don't waste
8 bytes passing it.

tdb2: hoist adjust_size

We're going to want it in get_free() in the next patch, so move it upwards.
Trivial changes, too: add to size before min length check, and rename growing
to want_extra.

tdb2: clean up makefile for tools

tdb2: extra debugging checks

ccanlint: add ccanlint section to _info

This supersedes the previous Fails: section, into a more general set of
lines of form:

      <testname> <option>...

With the special <option> "FAIL" to mean we know we fail this test.
We accept options to valgrind-tests; in particular tdb2 wants
--partial-loads-ok=yes passed to valgrind.

ccanlint: override _info's Fails: with --target

I wanted to see what happened with tdb2's valgrind test (suppressed in the
_info file).

ccanlint: run tests in alphabetical order

This allows tests (like in tdb2) to run the simpler tests first and build up,
making it easier to spot the root cause of errors.

config: add HAVE_BUILTIN_FFSLL

nfs: remove trailing whitespace

ccanlint complained about it; it's trivial but fixing it adds one point to
our score.

nfs: make headers idempotent

ccanlint did this automatically.

nfs: Remove _U_, use ccan/compiler and UNUSED

Also, add Author and License lines to _info (ccanlint complained).
Now ccanlint can build it as a module.

nfs: Add _info, remove -D_FILE_OFFSET_BITS=64, use nfs_off_t

This makes it closer to compiling under ccanlint.

ccanlint: remove -Werror, use output of compile command to detect warnings.

This means we can pass various compulation tests, but deduct points if
they get warnings.

ccanlint: make compile commands return output.

We want to distinguish between warnings and errors: the first step is to
return the output even if the command doesn't fail.

ccanlint: fix idempotent handler

Test for inserting idempotent header was wrong way around, and we check
all headers at once, rather than finishing after one.

Also, turn - into _ rather than removing.

ccanlint: only print 5 lines of output unless -vv

ccanlint: print error information even if we pass.

This means we can see messages even if we don't fail; ie. for compiler warnings
once they are no longer fatal.

This means that various tests have to be more careful in not setting
score->error.

ccanlint: minor print formatting cleanup.

ccanlint: don't skip every second question

We only grabbed one character at a time from stdin, so "y<return>" answered
the next question as well.

ciniparser: add LICENSE symlink

foreach, iscsi, jbitset, jmap, opt, rbtree, sparse_bsearch, tally, tdb2: add LICENSE symlinks

ccanlint: check license and LICENSE symlink.

Michael Ellerman noted that ccan/opt has no symlink, so add ccanlint test.

ccanlint: clarify different -v levels.

ccanlint: fix --target=examples-compile

ccanlint: use isspace instead of isblank

I am told that CentOS 5.3 doesn't like isblank (it's ISO C).

ccan_tokenizer, check_type, container_of, typesafe_cb: handle !HAVE_TYPEOF

Delio Brignoli points out that check_type fails when HAVE_TYPEOF is 0,
so turn that off here and see what else breaks...

ccanlint: typo fix and fix errant description parsing.

"C has fairly weak typing:" from check_type/_info is not a new section heading!
Enforce that each word in multi-word sections must be caps.

ccanlint: tweak example compilation.

We used to prefer to build up examples using previous ones, but this broke
for tests which were to be executed.  But list.h relied on the buildup
behavior, so return to that unless we see "// Given" comments indicating
an execution test.

list: fix uninitialized variable in list_add example.

gcc with optimization complained (correctly) about this.

ccanlint: list file errors in order they are encountered.

ccanlint: fix abort when -vv used and examples don't compile.

Makefile: exclude Judy-depending libraries as well as nfs

(nfs gives warnings on build, make ccanlint unhappy).

Merge branch 'ronnie'

compiler: shorten names of attributes, add UNUSED

The long names were unwieldy in practice; at risk of clashing, replace
with shorter versions.

nfs: add generates C files

ccanlint won't run rpcgen, so we need the C source in the repo anyway.

nfs: ccanize a little more.

rename libnfs.h to nfs.h (CCAN expects "main" header to match module name).
tools move into tools/, .x file move into rpc/
Don't sed the rpcgen files, generate headers in rpc/
Make tools use <ccan/nfs/nfs.h> as per normal ccan usage.

nfs: initial import.

Another Ronnie module!

ccanlint: rework so checks have more structure.

Previously each check returned a void *, but in fact most of them fell into
similar patterns.  So define 'struct score' and a helper to add files to it,
and use that.

Under these rules, you get 0/1 if you skip a test because a dependency failed
which in theory means your score (as a percentage) could drop if you fix
a test.

ccanlint: fix up creation of test/run.c

Make test directory correctly, and #include <ccan/...> not #include "".

likely: switch from using ccan/hashtable to ccan/htable

rbtree: new module from Ronnie.

hashtable: replaced by htable.

talloc: define TALLOC_CTX

I'm not a fan of the SHOUTING, but it's upstream.

iscsi: add LICENCE link

iscsi: ccanize a little more, add silly simple test case.

iscsi: new module from Ronnie.

htable: push capacity limit from 66 to 75%

With the extra bits, long runs don't hurt our cache very much on search,
so we can pack quite a few in.  Here are the runs at maximal density before
and after:

Before:
$ ./speed 3145000
Initial insert:  248 ns
Details: hash size 4194304, mask bits 9, perfect 63%
Initial lookup (match):  122 ns
Initial lookup (miss):  142 ns
Initial lookup (random):  170 ns
Initial delete all:  134 ns
Details: rehashes 3145000
Initial re-inserting:  149 ns
Deleting first half:  73 ns
Details: rehashes 1572500, delete markers 1572500
Adding (a different) half:  128 ns
Details: delete markers 0, perfect 62%
Lookup after half-change (match):  129 ns
Lookup after half-change (miss):  145 ns
Details: initial churn
Churning second time:  703 ns
Churning third time:  725 ns
Churning fourth time:  717 ns
Churning fifth time:  710 ns
Details: reinserting with spread
Details: delete markers 149261, perfect 57%
Details: worst run 254 (2 deleted)
Lookup after churn & spread (match):  132 ns
Lookup after churn & spread (miss):  159 ns
Lookup after churn & spread (random):  184 ns
Deleting half after churn & spread:  71 ns
Adding (a different) half after churn & spread:  129 ns
Details: delete markers 0, perfect 62%

After:
$ ./speed 3145727
Initial insert:  232 ns
Details: hash size 4194304, mask bits 9, perfect 63%
Initial lookup (match):  122 ns
Initial lookup (miss):  141 ns
Initial lookup (random):  234 ns
Initial delete all:  129 ns
Details: rehashes 3145727
Initial re-inserting:  153 ns
Deleting first half:  80 ns
Details: rehashes 1572864, delete markers 1572864
Adding (a different) half:  137 ns
Details: delete markers 0, perfect 62%
Lookup after half-change (match):  125 ns
Lookup after half-change (miss):  145 ns
Details: initial churn
Churning second time:  702 ns
Churning third time:  719 ns
Churning fourth time:  712 ns
Churning fifth time:  709 ns
Details: reinserting with spread
Details: delete markers 169474, perfect 56%
Details: worst run 248 (12 deleted)
Lookup after churn & spread (match):  129 ns
Lookup after churn & spread (miss):  159 ns
Lookup after churn & spread (random):  242 ns
Deleting half after churn & spread:  70 ns
Adding (a different) half after churn & spread:  133 ns
Details: delete markers 0, perfect 62%

htable: restore perfect bit when resizing.

If the lower bit differs between pointers, we can lose our "perfect"
bit.  Since we're rehashing the entire thing anyway, we can pick
another bit when we double the hash table.

htable: use "perfect" bit to reduce rehashes.

Steal one bit to indicate an entry is in its perfect position.  This
means we don't have to rehash it when we are rehashing the entire
table to get rid of deleted records, and we can still use it for
comparison during lookup.

Before: $ ./speed 50000000
Initial insert:  462 ns
Details: hash size 134217728, mask bits 5, perfect 81%
Initial lookup (match):  161 ns
Initial lookup (miss):  168 ns
Initial lookup (random):  326 ns
Initial delete all:  164 ns
Details: rehashes 50000000
Initial re-inserting:  167 ns
Deleting first half:  86 ns
Details: rehashes 25000000, delete markers 25000000
Adding (a different) half:  217 ns
Details: delete markers 0, perfect 81%
Lookup after half-change (match):  169 ns
Lookup after half-change (miss):  180 ns
Details: initial churn
Churning second time:  593 ns
Churning third time:  611 ns
Churning fourth time:  619 ns
Churning fifth time:  622 ns
Details: reinserting with spread
Details: delete markers 13800468, perfect 73%
Details: worst run 48 (4 deleted)
Lookup after churn & spread (match):  192 ns
Lookup after churn & spread (miss):  211 ns
Lookup after churn & spread (random):  373 ns
Deleting half after churn & spread:  103 ns
Adding (a different) half after churn & spread:  102 ns
Details: delete markers 29539689, perfect 72%

After:
Initial insert:  467 ns
Details: hash size 134217728, mask bits 5, perfect 81%
Initial lookup (match):  163 ns
Initial lookup (miss):  171 ns
Initial lookup (random):  326 ns
Initial delete all:  170 ns
Details: rehashes 50000000
Initial re-inserting:  169 ns
Deleting first half:  88 ns
Details: rehashes 25000000, delete markers 25000000
Adding (a different) half:  141 ns
Details: delete markers 0, perfect 81%
Lookup after half-change (match):  166 ns
Lookup after half-change (miss):  171 ns
Details: initial churn
Churning second time:  441 ns
Churning third time:  469 ns
Churning fourth time:  466 ns
Churning fifth time:  490 ns
Details: reinserting with spread
Details: delete markers 13800468, perfect 73%
Details: worst run 48 (4 deleted)
Lookup after churn & spread (match):  197 ns
Lookup after churn & spread (miss):  209 ns
Lookup after churn & spread (random):  369 ns
Deleting half after churn & spread:  98 ns
Adding (a different) half after churn & spread:  100 ns
Details: delete markers 29539689, perfect 72%

htable: rehash to clear delete markers

Delete markers build up over time, even if we try to clean as we go.
So just garbage collect them when there are too many.

Before:
rusty@vivaldi:~/devel/cvs/ccan/ccan/htable/tools (htable)$ ./speed 50000000
Initial insert:  467 ns
Details: hash size 134217728, mask bits 5, perfect 81%
Initial lookup (match):  160 ns
Initial lookup (miss):  169 ns
Initial lookup (random):  328 ns
Initial delete all:  165 ns
Details: rehashes 50000000
Initial re-inserting:  317 ns
Deleting first half:  86 ns
Details: rehashes 25000000, delete markers 25000000
Adding (a different) half:  89 ns
Details: delete markers 18894324, perfect 76%
Lookup after half-change (match):  174 ns
Lookup after half-change (miss):  203 ns
Details: initial churn
Churning second time:  816 ns
Churning third time:  615 ns
Churning fourth time:  621 ns
Churning fifth time:  846 ns
Details: reinserting with spread
Details: delete markers 11078719, perfect 74%
Details: worst run 48 (4 deleted)
Lookup after churn & spread (match):  191 ns
Lookup after churn & spread (miss):  208 ns
Lookup after churn & spread (random):  374 ns
Deleting half after churn & spread:  102 ns
Adding (a different) half after churn & spread:  103 ns
Details: delete markers 27442234, perfect 73%

After:
Initial insert:  462 ns
Details: hash size 134217728, mask bits 5, perfect 81%
Initial lookup (match):  161 ns
Initial lookup (miss):  168 ns
Initial lookup (random):  326 ns
Initial delete all:  164 ns
Details: rehashes 50000000
Initial re-inserting:  167 ns
Deleting first half:  86 ns
Details: rehashes 25000000, delete markers 25000000
Adding (a different) half:  217 ns
Details: delete markers 0, perfect 81%
Lookup after half-change (match):  169 ns
Lookup after half-change (miss):  180 ns
Details: initial churn
Churning second time:  593 ns
Churning third time:  611 ns
Churning fourth time:  619 ns
Churning fifth time:  622 ns
Details: reinserting with spread
Details: delete markers 13800468, perfect 73%
Details: worst run 48 (4 deleted)
Lookup after churn & spread (match):  192 ns
Lookup after churn & spread (miss):  211 ns
Lookup after churn & spread (random):  373 ns
Deleting half after churn & spread:  103 ns
Adding (a different) half after churn & spread:  102 ns
Details: delete markers 29539689, perfect 72%