Re: [RFC][PATCH] mm: sl[uo]b: fix misleading comments
Acked-by: Christoph Lameter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] mm: sl[uo]b: fix misleading comments
Acked-by: Christoph Lameter c...@linux.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] mm: sl[uo]b: fix misleading comments
On Tue, 28 Jan 2014, Dave Hansen wrote: > From: Dave Hansen > > 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 Acked-by: David Rientjes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH] mm: sl[uo]b: fix misleading comments
From: Dave Hansen
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
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: Matt Mackall
Cc: Andrew Morton
---
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH] mm: sl[uo]b: fix misleading comments
From: Dave Hansen dave.han...@linux.intel.com
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 dave.han...@linux.intel.com
Cc: Christoph Lameter c...@linux-foundation.org
Cc: Pekka Enberg penb...@kernel.org
Cc: Matt Mackall m...@selenic.com
Cc: Andrew Morton a...@linux-foundation.org
---
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] mm: sl[uo]b: fix misleading comments
On Tue, 28 Jan 2014, Dave Hansen wrote: From: Dave Hansen dave.han...@linux.intel.com 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 dave.han...@linux.intel.com Acked-by: David Rientjes rient...@google.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
