[PATCH] infrastructure for handling radix_tree_node allocation
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.
Showing
Please register or sign in to comment