alf_queue: playing with a masked based load/store

Trying out a mask based version of the __helper_alf for
enqueue_store's and dequeue_load's.

This didn't change the performance.

Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
mm: qmempool: a quick queue based mempool

A quick or queue-based memory pool, that functions as a cache
in-front of kmem_cache SLAB/SLUB allocators.

A quick queue-based memory pool, that functions as a cache in-front
of kmem_cache SLAB/SLUB allocators.  Which allows faster than
SLAB/SLUB reuse/caching of fixed size memory elements

The speed gain comes from, the shared storage, using a Lock-Free
queue that supports bulking elements with a single cmpxchg.

The Lock-Free queue is based on an array (of pointer to elements).
This make access more cache optimal, as e.g. on 64bit 8 pointers
can be stored per cache-line (which is superior to a linked list
approach).

Only storing the pointers to elements, is also beneficial as we
don't touch the elements data.

Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
scripts: push_remote.sh also upload kernel modules from "mm" dir

Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
qmempool_test: module that tests basic functionality of qmempool

Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
qmempool_bench: add module for micro benchmarking qmempool

First results.

Compared against SLUB, with .config:
 CONFIG_SLUB=y
 CONFIG_SLUB_CPU_PARTIAL=y
 CONFIG_PREEMPT_COUNT=y
 CONFIG_PREEMPT=n

Results from CPU E5-2695:

In the fast reuse case, the SLUB cost is 19.313 ns, while the
qmempool cost is only 9.267 ns (with only using preempt_disable).

qmempool_bench: Measured cost of doing alloc+free:

Type:kmem fastpath reuse Per elem: 48 cycles(tsc) 19.313 ns (step:0)
 - (measurement period time:0.579413741 sec time_interval:579413741)
 - (invoke count:30000000 tsc_interval:1448533222)

Type:qmempool fastpath reuse Per elem: 23 cycles(tsc) 9.267 ns (step:0)
 - (measurement period time:0.278013891 sec time_interval:278013891)
 - (invoke count:30000000 tsc_interval:695033972)


The interesting comparison is the usage pattern of allocating 256
elements before freeing them again.  The qmempool only have 32
local CPU elements, thus it must go through the sharedq to get
enough resources, but have enough shared 256 elements to avoid
calling the real slab.

The cost of SLUB increased to 37.570 ns, while the qmempool cost
only increased to 12.539 ns.  This shows qmempool have
successfully amortized the cost of the expensive locked cmpxchg.

qmempool_bench: N-pattern with 256 elements:

Type:kmem alloc+free N-pattern Per elem: 93 cycles(tsc) 37.570 ns (step:0)
 - (measurement period time:0.961808098 sec time_interval:961808098)
 - (invoke count:25600000 tsc_interval:2404518787)

Type:qmempool alloc+free N-pattern Per elem: 31 cycles(tsc) 12.539 ns (step:0)
 - (measurement period time:0.321023810 sec time_interval:321023810)
 - (invoke count:25600000 tsc_interval:802558657)

If we need to use more expensive preemptive avoidance technique,
like local_bh_{disable,enable} or local_irq_{save,restore}, then
the qmempool cost goes up, but still maintains better performance
than SLUB.

Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>