The keyword huge tend to remind people of huge pages which is not relevent to
the feature.

This feature uses an dedicated arena to handle huge requests, which
significantly improves VM fragmentation.  In production workload we tested it
often reduces VM size by >30%.

This helps us avoid issues with size based routing (i.e. the huge_threshold
feature).

The rate calculation for the total row was missing.

For low arena count settings, the huge threshold feature may trigger an unwanted
bg thd creation.  Given that the huge arena does eager purging by default,
bypass bg thd creation when initializing the huge arena.

This reverts commit 646af596.

This reverts commit fc13a7f1.

When custom extent_hooks or transparent huge pages are in use, the purging
semantics may change, which means we may not get zeroed pages on repopulating.
Fixing the issue by manually memset for such cases.

The --branch parameter is unnecessary, and may avoid problems when
testing directly on the dev branch.

This automatically adds -latomic if and when needed, e.g. on riscv64
systems.

Fixes #1401.

My distro offers a custom toolchain where it's not possible to make
static libs, so it's insufficient to just delete the libs I don't want.
I actually need to avoid building them in the first place.

Add exten_arena_ind_get() to avoid loading the actual arena ptr in case we just
need to check arena matching.

With sharded bins, we may not flush all items from the same arena in one run.
Adjust the stats merging logic accordingly.

This avoids having to choose bin shard on the fly, also will allow flexible bin
binding for each thread.

The option uses the same format as "slab_sizes" to specify number of shards for
each bin size.

This makes it possible to have multiple set of bins in an arena, which improves
arena scalability because the bins (especially the small ones) are always the
limiting factor in production workload.

A bin shard is picked on allocation; each extent tracks the bin shard id for
deallocation.  The shard size will be determined using runtime options.

If there are 3 or more threads spin-waiting on the same mutex,
there will be excessive exclusive cacheline contention because
pthread_trylock() immediately tries to CAS in a new value, instead
of first checking if the lock is locked.

This diff adds a 'locked' hint flag, and we will only spin wait
without trylock()ing while set.  I don't know of any other portable
way to get the same behavior as pthread_mutex_lock().

This is pretty easy to test via ttest, e.g.

./ttest1 500 3 10000 1 100

Throughput is nearly 3x as fast.

This blames to the mutex profiling changes, however, we almost never
have 3 or more threads contending in properly configured production
workloads, but still worth fixing.

The setting has been tested in production for a while.  No negative effect while
we were able to reduce number of threads per process.

Also adds a configure.ac check for __builtin_popcount, which is used
in the new fastpath.

Refactor tcache_fill, introducing a new function arena_slab_reg_alloc_batch,
which will fill multiple pointers from a slab.

There should be no functional changes here, but allows future optimization
on reg_alloc_batch.

We may have a large number of pages with *zero set (since they are populated on
demand).  Only check the first page to avoid paging in all of them.

Also catch invalid tcache id.

Add unsized and sized deallocation fastpaths.  Similar to the malloc()
fastpath, this removes all frame manipulation for the majority of
free() calls.  The performance advantages here are less than that
of the malloc() fastpath, but from prod tests seems to still be half
a percent or so of improvement.

Stats and sampling a both supported (sdallocx needs a sampling check,
for rtree lookups slab will only be set for unsampled objects).

We don't support flush, any flush requests go to the slowpath.

Add a cache_bin_dalloc_easy (to match the alloc_easy function),
and use it in tcache_dalloc_small.  It will also be used in the
new free fastpath.

For a free fastpath, we want something that will not make additional
calls.  Assume most free() calls will hit the L1 cache, and use
a custom rtree function for this.

Additionally, roll the ptr=NULL check in to the rtree cache check.

It was removed in 0771ff2c.
Add a comment explaining its purpose.