net channels: don't drop packet when the channel is full

classifier::post_packet() uses net_channel::push() to queue a received
packet on the appropriate net channel. However, push() can return false
meaning the channel is full, and we neglect to check it.

By not checking if push() succeeded, and returning "true" from post_packet
anyway, we basically drop this packet. This will be bad for TCP performance
because it will lead the remote side to reduce its transmission rate.
Even worse, we don't even drop the packet correctly - we never free the
dropped mbuf, and its memory is leaked.

With this patch, when the net channel is full, post_packet() returns
false which leads the caller (net::receiver()) to use the normal TCP
stack on this packet. The TCP stack (tcp_input()) will consume the
packets queued in the netchannel first (tcp_flush_net_channel()) and
then the new packet.

Reviewed-by: Avi Kivity <avi@cloudius-systems.com>
Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
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>