slub: Support 4k kmallocs again to compensate for page allocator slowness
commit331dc558fa020451ff773973cee855fd721aa88e
authorChristoph Lameter <clameter@sgi.com>
Thu, 14 Feb 2008 22:28:09 +0000 (14 14:28 -0800)
committerChristoph Lameter <christoph@stapp.engr.sgi.com>
Thu, 14 Feb 2008 23:30:02 +0000 (14 15:30 -0800)
tree12adf10a7e53c8d07835487694d8180b991304cd
parent71c7a06ff0a2ba0434ace4d7aa679537c4211d9d
slub: Support 4k kmallocs again to compensate for page allocator slowness

Currently we hand off PAGE_SIZEd kmallocs to the page allocator in the
mistaken belief that the page allocator can handle these allocations
effectively. However, measurements indicate a minimum slowdown by the
factor of 8 (and that is only SMP, NUMA is much worse) vs the slub fastpath
which causes regressions in tbench.

Increase the number of kmalloc caches by one so that we again handle 4k
kmallocs directly from slub. 4k page buffering for the page allocator
will be performed by slub like done by slab.

At some point the page allocator fastpath should be fixed. A lot of the kernel
would benefit from a faster ability to allocate a single page. If that is
done then the 4k allocs may again be forwarded to the page allocator and this
patch could be reverted.

Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi>
Acked-by: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Christoph Lameter <clameter@sgi.com>
include/linux/slub_def.h
mm/slub.c