Force emergency allocations to trigger under low memory conditions

A concept of an emergency allocation was introduced last year to permit
allocations that took excessive periods of time to switch to physical
memory to make forward progress. Emergency allocations currently occur
by setting a flag, telling kmem_cache_alloc() to try again and then
doing the allocation. This is useful, but it might not always trigger
because we do not permit allocations in the spl_cache_grow() to
retry. This permits allocation failures to fail before the timer for
emergency allocations can trigger. This will result in a return to
kmem_cache_alloc(), which will then repeat the process. The result is
that we can loop infinitely without any forward progress under low
memory conditions because the emergency allocations will not trigger.

We change the code to force the worker to retry indefinitely. This
guarentees that the emergency allocations will trigger under low memory
conditions.

Signed-off-by: Richard Yao <ryao@gentoo.org>
Preallocate memory for spl_kmem_alloc_t in spl_kmem_cache_t

Signed-off-by: Richard Yao <ryao@gentoo.org>
Use pages for emergency allocations when possible

A concept of an emergency allocation was introduced last year to permit
allocations that took excessive periods of time to switch to physical
memory to make forward progress.

Unfortunately, the Linux kernel's physical memory allocator does SLAB
allocation for all allocations less than or equal to 8192. It is
possible for Linux's SLAB allocator to invoke direct reclaim when
allocating new slabs. This can cause swap to deadlock. Additionally,
memory fragmentation is able to cause allocations to hang whenever an
allocation is made from a cache that uses slabs that span multiple
pages. In specific, whenever the allocation is greater than 256-bytes.

Whenever an emergency object is small enough to fit into a single page
and we allocate a page for the emergency allocation instead of going
through kmalloc(). If the object and its ske header cannot fit together
in a single page, we allocate two non-contiguous pages. Larger object
sizes are still at risk, but there is little we can do for them.

Signed-off-by: Richard Yao <ryao@gentoo.org>
Implement sgbufs

sgbufs are scatter-gather buffers that consist of pages that can
be manipulated directly or mapped itno the page tables on an as-needed
basis. This a new data structure that will be proposed for inclusion
into Illumos. Their main purpose is a replacement for slab allocation in
ZIO buffers.

Signed-off-by: Richard Yao <ryao@gentoo.org>