memory: Global page buffer pool

Currently, we maintain a percpu page buffer pool for page allocator.
When the pool is empty or full, the global mutex free_page_ranges_lock
is take to refill or unfill the pool.

This patch introduces a global page buffer pool in addition to the
percpu page buffer pool.

1) L1-pool (Percpu page buffer pool)

if nr < max * 1 / 4
   refill

if nr > max * 3 / 4
   unfill

2) L2-pool (Global page buffer pool)

if nr < max * 1 / 4
   refill

if nr > max * 3 / 4
   unfill

When L1-pool needs refill or unfill, it moves a batch of pages from or to
L2-pool.

When L2-pool needs refill or unfill, it move a batch of pages from or to
global free page list.

Some notes:

- On fast path, both L1 and L2 allocation/deallocation require no lock.

- Atomic operations amortized to a large number of pages.
  Pages are exchanged in batch (currently 32 pages) between L1 and L2
  and global pool.

- Percpu threads are added for L1-pool refill/unfill. This looks
  over-killing, but there seems no other better way to do it.
  One option is to use async::run_later interface, but the refill/unfill
  operation will block, thus blocking other tasks on the same cpu.
  Another option is to use core/percpu-worker.cc interface. Again, it
  will block other tasks. For now, I am using per-cpu thread approach.

- nr_cpus(L1 pool) + 1(L2 pool) additional threads are added compared to
  current allocator. These threads help filling the pool more
  aggressively: at 1/4 - 3/4 level, compared to 0 - 1 level.

Tests:

1) I used /tests/misc-malloc.so to stress memory allocation/deallocation.

   for i in `seq 100`; do
       sudo scripts/run.py -nv -c16 -m16g -e "/tests/misc-malloc.so";
   done

100 round of tests passed.

2) tomcat + wrk

Running 10s test @ http://192.168.122.89:8081/servlet/json
Running 1m test @ http://192.168.122.89:8081/servlet/json

20 round of tests passed

Signed-off-by: Asias He <asias@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>