radix_tree_node_alloc() uses GFP_ATOMIC, under spinlocking.  If the
allocation fails then userspace sees ENOMEM and application failure occurs.

A single add_to_page_cache() will require up to six radix_tree_nodes on
32-bit machines, twice this on 64-bit machines (quadruple the worst-case
storage on 64-bit).

My approach to solving this problem is to create a per-cpu pool of
preallocated radix_tree_nodes, private to the radix-tree code.

The radix-tree user will call the new radix-tree API function
radix_tree_preload() to ensure that this pool has sufficient nodes to cover
the worst-case.  radix_tree_preload() should be called outside locks, with
GFP_KERNEL so that it can run page reclaim.

If it succeeds, radix_tree_preload() will return with preemption disabled so
that the per-cpu radix_tree_node pool is protected.  The user must call
radix_tree_preload_end() to terminate the transaction.

In the common case, the per-cpu pools will never be touched:
radix_tree_insert() will only dip into the pool if kmem_cache_alloc() fails.
The pools will remain full at all times.  This is to optimise the fastpath -
it is just a few instructions.

This patch also removes the now-unneeded radix-tree mempool.  This saves 130
kbytes of permanently allocated kernel memory.  260k on 64-bit platforms.