From: Dave Hansen <[email protected]> On x86, SLUB creates and handles <=8192-byte allocations internally. It passes larger ones up to the allocator. Saying "up to order 2" is, at best, ambiguous. Is that order-1? Or (order-2 bytes)? Make it more clear.
SLOB commits a similar sin. It *handles* page-size requests, but the comment says that it passes up "all page size and larger requests". SLOB also swaps around the order of the very-similarly-named KMALLOC_SHIFT_HIGH and KMALLOC_SHIFT_MAX #defines. Make it consistent with the order of the other two allocators. Signed-off-by: Dave Hansen <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: Matt Mackall <[email protected]> Cc: Andrew Morton <[email protected]> --- b/include/linux/slab.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff -puN include/linux/slab.h~mm-slub-off-by-one-comment-on-kmalloc-max include/linux/slab.h --- a/include/linux/slab.h~mm-slub-off-by-one-comment-on-kmalloc-max 2014-01-28 13:27:50.883108273 -0800 +++ b/include/linux/slab.h 2014-01-28 13:27:50.886108408 -0800 @@ -205,8 +205,8 @@ struct kmem_cache { #ifdef CONFIG_SLUB /* - * SLUB allocates up to order 2 pages directly and otherwise - * passes the request to the page allocator. + * SLUB directly allocates requests fitting in to an order-1 page + * (PAGE_SIZE*2). Larger requests are passed to the page allocator. */ #define KMALLOC_SHIFT_HIGH (PAGE_SHIFT + 1) #define KMALLOC_SHIFT_MAX (MAX_ORDER + PAGE_SHIFT) @@ -217,12 +217,12 @@ struct kmem_cache { #ifdef CONFIG_SLOB /* - * SLOB passes all page size and larger requests to the page allocator. + * SLOB passes all requests larger than one page to the page allocator. * No kmalloc array is necessary since objects of different sizes can * be allocated from the same page. */ -#define KMALLOC_SHIFT_MAX 30 #define KMALLOC_SHIFT_HIGH PAGE_SHIFT +#define KMALLOC_SHIFT_MAX 30 #ifndef KMALLOC_SHIFT_LOW #define KMALLOC_SHIFT_LOW 3 #endif _ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
