alloc loop now attempts an item_lock

Fixes a few issues with a restructuring... I think -M was broken before,
should be fixed now. It had a refcount leak.

Now walks up to five items from the bottom in case of the bottomost items
being item_locked, or refcount locked. Helps avoid excessive OOM errors for
some oddball cases. Those happen more often if you're hammering on a handful
of pages in a very large class size (100k+)

The hash item lock ensures that if we're holding that lock, no other thread
can be incrementing the refcount lock at that time. It will mean more in
future patches.

slab rebalancer gets a similar update.

1 files changed, 1 insertions, 1 deletions

diff --git a/items.h b/items.h
index 2ec142d..4b25dcc 100644
--- a/items.h
+++ b/items.h
@@ -2,7 +2,7 @@
 uint64_t get_cas_id(void);
 
 /*@null@*/
-item *do_item_alloc(char *key, const size_t nkey, const int flags, const rel_time_t exptime, const int nbytes);
+item *do_item_alloc(char *key, const size_t nkey, const int flags, const rel_time_t exptime, const int nbytes, const uint32_t cur_hv);
 void item_free(item *it);
 bool item_size_ok(const size_t nkey, const int flags, const int nbytes);