[RFC] Extract kmalloc.h and slob.h from slab.h

[RFC] Extract kmalloc.h and slob.h from slab.h

[Christoph Lameter]

slab.h really defines multiple APIs. One is the classic slab api
where one can define a slab cache by specifying exactly how
the slab has to be generated. This API is not frequently used.

Another is the kmalloc API. Quite a number of kernel source code files 
need kmalloc but do not need to generate custom slabs. The kmalloc API 
also use some funky macros that may be better isolated in an additional .h 
file in order to ease future cleanup. Make kmalloc.h self contained by 
adding two extern definitions local to kmalloc and kmalloc_node.

Then there is the SLOB api mixed in with slab. Take that out and define it 
in its own header file.

Signed-off-by: Christoph Lameter <clameter@sgi.com>

Index: linux-2.6.19-rc6-mm1/include/linux/kmalloc.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.19-rc6-mm1/include/linux/kmalloc.h	2006-11-27 21:57:25.000000000 -0800
@@ -0,0 +1,221 @@
+#ifndef _LINUX_KMALLOC_H
+#define	_LINUX_KMALLOC_H
+
+#include <linux/gfp.h>
+#include <asm/page.h>		/* kmalloc_sizes.h needs PAGE_SIZE */
+#include <asm/cache.h>		/* kmalloc_sizes.h needs L1_CACHE_BYTES */
+
+#ifdef __KERNEL__
+
+/* Size description struct for general caches. */
+struct cache_sizes {
+	size_t		 cs_size;
+	struct kmem_cache *cs_cachep;
+#ifdef CONFIG_ZONE_DMA
+	struct kmem_cache *cs_dmacachep;
+#else
+#define cs_dmacachep cs_cachep
+#endif
+};
+extern struct cache_sizes malloc_sizes[];
+
+extern void *__kmalloc(size_t, gfp_t);
+
+/**
+ * kmalloc - allocate memory
+ * @size: how many bytes of memory are required.
+ * @flags: the type of memory to allocate.
+ *
+ * kmalloc is the normal method of allocating memory
+ * in the kernel.
+ *
+ * The @flags argument may be one of:
+ *
+ * %GFP_USER - Allocate memory on behalf of user.  May sleep.
+ *
+ * %GFP_KERNEL - Allocate normal kernel ram.  May sleep.
+ *
+ * %GFP_ATOMIC - Allocation will not sleep.
+ *   For example, use this inside interrupt handlers.
+ *
+ * %GFP_HIGHUSER - Allocate pages from high memory.
+ *
+ * %GFP_NOIO - Do not do any I/O at all while trying to get memory.
+ *
+ * %GFP_NOFS - Do not make any fs calls while trying to get memory.
+ *
+ * Also it is possible to set different flags by OR'ing
+ * in one or more of the following additional @flags:
+ *
+ * %__GFP_COLD - Request cache-cold pages instead of
+ *   trying to return cache-warm pages.
+ *
+ * %__GFP_DMA - Request memory from the DMA-capable zone.
+ *
+ * %__GFP_HIGH - This allocation has high priority and may use emergency pools.
+ *
+ * %__GFP_HIGHMEM - Allocated memory may be from highmem.
+ *
+ * %__GFP_NOFAIL - Indicate that this allocation is in no way allowed to fail
+ *   (think twice before using).
+ *
+ * %__GFP_NORETRY - If memory is not immediately available,
+ *   then give up at once.
+ *
+ * %__GFP_NOWARN - If allocation fails, don't issue any warnings.
+ *
+ * %__GFP_REPEAT - If allocation fails initially, try once more before failing.
+ */
+static inline void *kmalloc(size_t size, gfp_t flags)
+{
+	extern void *kmem_cache_alloc(struct kmem_cache *, gfp_t);
+
+	if (__builtin_constant_p(size)) {
+		int i = 0;
+#define CACHE(x) \
+		if (size <= x) \
+			goto found; \
+		else \
+			i++;
+#include "kmalloc_sizes.h"
+#undef CACHE
+		{
+			extern void __you_cannot_kmalloc_that_much(void);
+			__you_cannot_kmalloc_that_much();
+		}
+found:
+		return kmem_cache_alloc((flags & GFP_DMA) ?
+			malloc_sizes[i].cs_dmacachep :
+			malloc_sizes[i].cs_cachep, flags);
+	}
+	return __kmalloc(size, flags);
+}
+
+/*
+ * kmalloc_track_caller is a special version of kmalloc that records the
+ * calling function of the routine calling it for slab leak tracking instead
+ * of just the calling function (confusing, eh?).
+ * It's useful when the call to kmalloc comes from a widely-used standard
+ * allocator where we care about the real place the memory allocation
+ * request comes from.
+ */
+#ifndef CONFIG_DEBUG_SLAB
+#define kmalloc_track_caller(size, flags) \
+	__kmalloc(size, flags)
+#else
+extern void *__kmalloc_track_caller(size_t, gfp_t, void*);
+#define kmalloc_track_caller(size, flags) \
+	__kmalloc_track_caller(size, flags, __builtin_return_address(0))
+#endif
+
+extern void *__kzalloc(size_t, gfp_t);
+
+/**
+ * kzalloc - allocate memory. The memory is set to zero.
+ * @size: how many bytes of memory are required.
+ * @flags: the type of memory to allocate (see kmalloc).
+ */
+static inline void *kzalloc(size_t size, gfp_t flags)
+{
+	extern void *kmem_cache_zalloc(struct kmem_cache *, gfp_t);
+
+	if (__builtin_constant_p(size)) {
+		int i = 0;
+#define CACHE(x) \
+		if (size <= x) \
+			goto found; \
+		else \
+			i++;
+#include "kmalloc_sizes.h"
+#undef CACHE
+		{
+			extern void __you_cannot_kzalloc_that_much(void);
+			__you_cannot_kzalloc_that_much();
+		}
+found:
+		return kmem_cache_zalloc((flags & GFP_DMA) ?
+			malloc_sizes[i].cs_dmacachep :
+			malloc_sizes[i].cs_cachep, flags);
+	}
+	return __kzalloc(size, flags);
+}
+
+/**
+ * kcalloc - allocate memory for an array. The memory is set to zero.
+ * @n: number of elements.
+ * @size: element size.
+ * @flags: the type of memory to allocate.
+ */
+static inline void *kcalloc(size_t n, size_t size, gfp_t flags)
+{
+	if (n != 0 && size > ULONG_MAX / n)
+		return NULL;
+	return kzalloc(n * size, flags);
+}
+
+extern void kfree(const void *);
+extern unsigned int ksize(const void *);
+
+#ifdef CONFIG_NUMA
+extern void *__kmalloc_node(size_t size, gfp_t flags, int node);
+
+static inline void *kmalloc_node(size_t size, gfp_t flags, int node)
+{
+	extern void *kmem_cache_alloc_node(struct kmem_cache *, gfp_t flags,
+								int node);
+
+	if (__builtin_constant_p(size)) {
+		int i = 0;
+#define CACHE(x) \
+		if (size <= x) \
+			goto found; \
+		else \
+			i++;
+#include "kmalloc_sizes.h"
+#undef CACHE
+		{
+			extern void __you_cannot_kmalloc_that_much(void);
+			__you_cannot_kmalloc_that_much();
+		}
+found:
+		return kmem_cache_alloc_node((flags & GFP_DMA) ?
+			malloc_sizes[i].cs_dmacachep :
+			malloc_sizes[i].cs_cachep, flags, node);
+	}
+	return __kmalloc_node(size, flags, node);
+}
+
+/*
+ * kmalloc_node_track_caller is a special version of kmalloc_node that
+ * records the calling function of the routine calling it for slab leak
+ * tracking instead of just the calling function (confusing, eh?).
+ * It's useful when the call to kmalloc_node comes from a widely-used
+ * standard allocator where we care about the real place the memory
+ * allocation request comes from.
+ */
+#ifndef CONFIG_DEBUG_SLAB
+#define kmalloc_node_track_caller(size, flags, node) \
+	__kmalloc_node(size, flags, node)
+#else
+extern void *__kmalloc_node_track_caller(size_t, gfp_t, int, void *);
+#define kmalloc_node_track_caller(size, flags, node) \
+	__kmalloc_node_track_caller(size, flags, node, \
+				__builtin_return_address(0))
+#endif
+#else
+static inline void *kmalloc_node(size_t size, gfp_t flags, int node)
+{
+	return kmalloc(size, flags);
+}
+
+#define kmalloc_node_track_caller(size, flags, node) \
+	kmalloc_track_caller(size, flags)
+#endif
+
+extern void __init kmem_cache_init(void);
+extern int slab_is_available(void);
+extern int kmem_cache_reap(int);
+
+#endif	/* __KERNEL__ */
+
+#endif	/* _LINUX_KMALLOC_H */
Index: linux-2.6.19-rc6-mm1/include/linux/slab.h
===================================================================
--- linux-2.6.19-rc6-mm1.orig/include/linux/slab.h	2006-11-27 21:56:49.000000000 -0800
+++ linux-2.6.19-rc6-mm1/include/linux/slab.h	2006-11-27 22:05:32.000000000 -0800
@@ -15,8 +15,6 @@
 #include	<linux/gfp.h>
 #include	<linux/init.h>
 #include	<linux/types.h>
-#include	<asm/page.h>		/* kmalloc_sizes.h needs PAGE_SIZE */
-#include	<asm/cache.h>		/* kmalloc_sizes.h needs L1_CACHE_BYTES */
 
 /* flags for kmem_cache_alloc() */
 #define	SLAB_NOFS		GFP_NOFS
@@ -53,11 +51,11 @@
 #define SLAB_CTOR_ATOMIC	0x002UL		/* tell constructor it can't sleep */
 #define	SLAB_CTOR_VERIFY	0x004UL		/* tell constructor it's a verify call */
 
-#ifndef CONFIG_SLOB
+#ifdef CONFIG_SLOB
+#include <linux/slob.h>
+#else
 
 /* prototypes */
-extern void __init kmem_cache_init(void);
-
 extern struct kmem_cache *kmem_cache_create(const char *,
 		size_t, size_t, unsigned long,
 		void (*)(void *, struct kmem_cache *, unsigned long),
@@ -69,258 +67,24 @@
 extern void kmem_cache_free(struct kmem_cache *, void *);
 extern unsigned int kmem_cache_size(struct kmem_cache *);
 extern const char *kmem_cache_name(struct kmem_cache *);
+extern int kmem_ptr_validate(struct kmem_cache *cachep, void *ptr);
 
-/* Size description struct for general caches. */
-struct cache_sizes {
-	size_t		 cs_size;
-	struct kmem_cache *cs_cachep;
-#ifdef CONFIG_ZONE_DMA
-	struct kmem_cache *cs_dmacachep;
-#else
-#define cs_dmacachep cs_cachep
-#endif
-};
-extern struct cache_sizes malloc_sizes[];
-
-extern void *__kmalloc(size_t, gfp_t);
-
-/**
- * kmalloc - allocate memory
- * @size: how many bytes of memory are required.
- * @flags: the type of memory to allocate.
- *
- * kmalloc is the normal method of allocating memory
- * in the kernel.
- *
- * The @flags argument may be one of:
- *
- * %GFP_USER - Allocate memory on behalf of user.  May sleep.
- *
- * %GFP_KERNEL - Allocate normal kernel ram.  May sleep.
- *
- * %GFP_ATOMIC - Allocation will not sleep.
- *   For example, use this inside interrupt handlers.
- *
- * %GFP_HIGHUSER - Allocate pages from high memory.
- *
- * %GFP_NOIO - Do not do any I/O at all while trying to get memory.
- *
- * %GFP_NOFS - Do not make any fs calls while trying to get memory.
- *
- * Also it is possible to set different flags by OR'ing
- * in one or more of the following additional @flags:
- *
- * %__GFP_COLD - Request cache-cold pages instead of
- *   trying to return cache-warm pages.
- *
- * %__GFP_DMA - Request memory from the DMA-capable zone.
- *
- * %__GFP_HIGH - This allocation has high priority and may use emergency pools.
- *
- * %__GFP_HIGHMEM - Allocated memory may be from highmem.
- *
- * %__GFP_NOFAIL - Indicate that this allocation is in no way allowed to fail
- *   (think twice before using).
- *
- * %__GFP_NORETRY - If memory is not immediately available,
- *   then give up at once.
- *
- * %__GFP_NOWARN - If allocation fails, don't issue any warnings.
- *
- * %__GFP_REPEAT - If allocation fails initially, try once more before failing.
- */
-static inline void *kmalloc(size_t size, gfp_t flags)
-{
-	if (__builtin_constant_p(size)) {
-		int i = 0;
-#define CACHE(x) \
-		if (size <= x) \
-			goto found; \
-		else \
-			i++;
-#include "kmalloc_sizes.h"
-#undef CACHE
-		{
-			extern void __you_cannot_kmalloc_that_much(void);
-			__you_cannot_kmalloc_that_much();
-		}
-found:
-		return kmem_cache_alloc((flags & GFP_DMA) ?
-			malloc_sizes[i].cs_dmacachep :
-			malloc_sizes[i].cs_cachep, flags);
-	}
-	return __kmalloc(size, flags);
-}
-
-/*
- * kmalloc_track_caller is a special version of kmalloc that records the
- * calling function of the routine calling it for slab leak tracking instead
- * of just the calling function (confusing, eh?).
- * It's useful when the call to kmalloc comes from a widely-used standard
- * allocator where we care about the real place the memory allocation
- * request comes from.
- */
-#ifndef CONFIG_DEBUG_SLAB
-#define kmalloc_track_caller(size, flags) \
-	__kmalloc(size, flags)
-#else
-extern void *__kmalloc_track_caller(size_t, gfp_t, void*);
-#define kmalloc_track_caller(size, flags) \
-	__kmalloc_track_caller(size, flags, __builtin_return_address(0))
-#endif
-
-extern void *__kzalloc(size_t, gfp_t);
-
-/**
- * kzalloc - allocate memory. The memory is set to zero.
- * @size: how many bytes of memory are required.
- * @flags: the type of memory to allocate (see kmalloc).
- */
-static inline void *kzalloc(size_t size, gfp_t flags)
-{
-	if (__builtin_constant_p(size)) {
-		int i = 0;
-#define CACHE(x) \
-		if (size <= x) \
-			goto found; \
-		else \
-			i++;
-#include "kmalloc_sizes.h"
-#undef CACHE
-		{
-			extern void __you_cannot_kzalloc_that_much(void);
-			__you_cannot_kzalloc_that_much();
-		}
-found:
-		return kmem_cache_zalloc((flags & GFP_DMA) ?
-			malloc_sizes[i].cs_dmacachep :
-			malloc_sizes[i].cs_cachep, flags);
-	}
-	return __kzalloc(size, flags);
-}
-
-/**
- * kcalloc - allocate memory for an array. The memory is set to zero.
- * @n: number of elements.
- * @size: element size.
- * @flags: the type of memory to allocate.
- */
-static inline void *kcalloc(size_t n, size_t size, gfp_t flags)
-{
-	if (n != 0 && size > ULONG_MAX / n)
-		return NULL;
-	return kzalloc(n * size, flags);
-}
-
-extern void kfree(const void *);
-extern unsigned int ksize(const void *);
-extern int slab_is_available(void);
+struct shrinker;
+extern void kmem_set_shrinker(kmem_cache_t *cachep, struct shrinker *shrinker);
 
 #ifdef CONFIG_NUMA
 extern void *kmem_cache_alloc_node(struct kmem_cache *, gfp_t flags, int node);
-extern void *__kmalloc_node(size_t size, gfp_t flags, int node);
-
-static inline void *kmalloc_node(size_t size, gfp_t flags, int node)
-{
-	if (__builtin_constant_p(size)) {
-		int i = 0;
-#define CACHE(x) \
-		if (size <= x) \
-			goto found; \
-		else \
-			i++;
-#include "kmalloc_sizes.h"
-#undef CACHE
-		{
-			extern void __you_cannot_kmalloc_that_much(void);
-			__you_cannot_kmalloc_that_much();
-		}
-found:
-		return kmem_cache_alloc_node((flags & GFP_DMA) ?
-			malloc_sizes[i].cs_dmacachep :
-			malloc_sizes[i].cs_cachep, flags, node);
-	}
-	return __kmalloc_node(size, flags, node);
-}
-
-/*
- * kmalloc_node_track_caller is a special version of kmalloc_node that
- * records the calling function of the routine calling it for slab leak
- * tracking instead of just the calling function (confusing, eh?).
- * It's useful when the call to kmalloc_node comes from a widely-used
- * standard allocator where we care about the real place the memory
- * allocation request comes from.
- */
-#ifndef CONFIG_DEBUG_SLAB
-#define kmalloc_node_track_caller(size, flags, node) \
-	__kmalloc_node(size, flags, node)
-#else
-extern void *__kmalloc_node_track_caller(size_t, gfp_t, int, void *);
-#define kmalloc_node_track_caller(size, flags, node) \
-	__kmalloc_node_track_caller(size, flags, node, \
-			__builtin_return_address(0))
-#endif
 #else /* CONFIG_NUMA */
 static inline void *kmem_cache_alloc_node(struct kmem_cache *cachep,
 					gfp_t flags, int node)
 {
 	return kmem_cache_alloc(cachep, flags);
 }
-static inline void *kmalloc_node(size_t size, gfp_t flags, int node)
-{
-	return kmalloc(size, flags);
-}
-
-#define kmalloc_node_track_caller(size, flags, node) \
-	kmalloc_track_caller(size, flags)
 #endif
 
-extern int FASTCALL(kmem_cache_reap(int));
-extern int FASTCALL(kmem_ptr_validate(struct kmem_cache *cachep, void *ptr));
-
-struct shrinker;
-extern void kmem_set_shrinker(kmem_cache_t *cachep, struct shrinker *shrinker);
-
-#else /* CONFIG_SLOB */
-
-/* SLOB allocator routines */
-
-void kmem_cache_init(void);
-struct kmem_cache *kmem_cache_create(const char *c, size_t, size_t,
-	unsigned long,
-	void (*)(void *, struct kmem_cache *, unsigned long),
-	void (*)(void *, struct kmem_cache *, unsigned long));
-void kmem_cache_destroy(struct kmem_cache *c);
-void *kmem_cache_alloc(struct kmem_cache *c, gfp_t flags);
-void *kmem_cache_zalloc(struct kmem_cache *, gfp_t);
-void kmem_cache_free(struct kmem_cache *c, void *b);
-const char *kmem_cache_name(struct kmem_cache *);
-void *kmalloc(size_t size, gfp_t flags);
-void *__kzalloc(size_t size, gfp_t flags);
-void kfree(const void *m);
-unsigned int ksize(const void *m);
-unsigned int kmem_cache_size(struct kmem_cache *c);
-
-static inline void *kcalloc(size_t n, size_t size, gfp_t flags)
-{
-	return __kzalloc(n * size, flags);
-}
-
-#define kmem_cache_shrink(d) (0)
-#define kmem_cache_reap(a)
-#define kmem_ptr_validate(a, b) (0)
-#define kmem_cache_alloc_node(c, f, n) kmem_cache_alloc(c, f)
-#define kmalloc_node(s, f, n) kmalloc(s, f)
-#define kzalloc(s, f) __kzalloc(s, f)
-#define kmalloc_track_caller kmalloc
-
-#define kmalloc_node_track_caller kmalloc_node
-
-struct shrinker;
-static inline void kmem_set_shrinker(kmem_cache_t *cachep,
-				     struct shrinker *shrinker) {}
+#include <linux/kmalloc.h>
 
-#endif /* CONFIG_SLOB */
+#endif /* !CONFIG_SLOB */
 
 #endif	/* __KERNEL__ */
 
Index: linux-2.6.19-rc6-mm1/include/linux/slob.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.19-rc6-mm1/include/linux/slob.h	2006-11-27 22:16:32.000000000 -0800
@@ -0,0 +1,47 @@
+#ifndef _LINUX_SLOB_H
+#define	_LINUX_SLOB_H
+
+#if	defined(__KERNEL__)
+
+#include <linux/slab.h>
+
+/* SLOB allocator routines */
+
+void kmem_cache_init(void);
+struct kmem_cache *kmem_cache_create(const char *c, size_t, size_t,
+	unsigned long,
+	void (*)(void *, struct kmem_cache *, unsigned long),
+	void (*)(void *, struct kmem_cache *, unsigned long));
+void kmem_cache_destroy(struct kmem_cache *c);
+void *kmem_cache_alloc(struct kmem_cache *c, gfp_t flags);
+void *kmem_cache_zalloc(struct kmem_cache *, gfp_t);
+void kmem_cache_free(struct kmem_cache *c, void *b);
+const char *kmem_cache_name(struct kmem_cache *);
+void *kmalloc(size_t size, gfp_t flags);
+void *__kzalloc(size_t size, gfp_t flags);
+void kfree(const void *m);
+unsigned int ksize(const void *m);
+unsigned int kmem_cache_size(struct kmem_cache *c);
+
+static inline void *kcalloc(size_t n, size_t size, gfp_t flags)
+{
+	return __kzalloc(n * size, flags);
+}
+
+#define kmem_cache_shrink(d) (0)
+#define kmem_cache_reap(a)
+#define kmem_ptr_validate(a, b) (0)
+#define kmem_cache_alloc_node(c, f, n) kmem_cache_alloc(c, f)
+#define kmalloc_node(s, f, n) kmalloc(s, f)
+#define kzalloc(s, f) __kzalloc(s, f)
+#define kmalloc_track_caller kmalloc
+
+#define kmalloc_node_track_caller kmalloc_node
+
+struct shrinker;
+static inline void kmem_set_shrinker(kmem_cache_t *cachep,
+				struct shrinker *shrinker) {}
+
+#endif	/* __KERNEL__ */
+
+#endif	/* _LINUX_SLOB_H */

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Pekka Enberg]

On 11/28/06, Christoph Lameter <clameter@sgi.com> wrote:
> @@ -0,0 +1,221 @@
> +#ifndef _LINUX_KMALLOC_H
> +#define        _LINUX_KMALLOC_H
> +
> +#include <linux/gfp.h>
> +#include <asm/page.h>          /* kmalloc_sizes.h needs PAGE_SIZE */
> +#include <asm/cache.h>         /* kmalloc_sizes.h needs L1_CACHE_BYTES */
> +
> +#ifdef __KERNEL__

This is an in-kernel header so why do we need the above #ifdef clause?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Christoph Lameter]

On Tue, 28 Nov 2006, Pekka Enberg wrote:

> On 11/28/06, Christoph Lameter <clameter@sgi.com> wrote:
> > @@ -0,0 +1,221 @@
> > +#ifndef _LINUX_KMALLOC_H
> > +#define        _LINUX_KMALLOC_H
> > +
> > +#include <linux/gfp.h>
> > +#include <asm/page.h>          /* kmalloc_sizes.h needs PAGE_SIZE */
> > +#include <asm/cache.h>         /* kmalloc_sizes.h needs L1_CACHE_BYTES */
> > +
> > +#ifdef __KERNEL__
> 
> This is an in-kernel header so why do we need the above #ifdef clause?

What exactly is an in-kernel header?

Why would slab.h be different from kmalloc.h? Yes currently kmalloc.h is 
included by slab.h but in the future code that only relies on kmalloc can 
just include kmalloc.h. Is it because it does not contain any constant 
definitions?


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Pekka J Enberg]

On Tue, 28 Nov 2006, Christoph Lameter wrote:
> What exactly is an in-kernel header?

One that is never ever included by userspace and thus does not need the 
guard clause.

On Tue, 28 Nov 2006, Christoph Lameter wrote:
> Why would slab.h be different from kmalloc.h? Yes currently kmalloc.h is 
> included by slab.h but in the future code that only relies on kmalloc can 
> just include kmalloc.h. Is it because it does not contain any constant 
> definitions?

I don't think <linux/slab.h> should have either but I suppose there can be 
other (broken) headers that include it and thus its safer not to remove 
the guard clause just yet. However, if you wrap the include of 
<linux/kmalloc.h> header inside the existing guard then we should be fine, 
no?

			Pekka

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Christoph Lameter]

On Tue, 28 Nov 2006, Pekka J Enberg wrote:

> I don't think <linux/slab.h> should have either but I suppose there can be 
> other (broken) headers that include it and thus its safer not to remove 
> the guard clause just yet. However, if you wrap the include of 
> <linux/kmalloc.h> header inside the existing guard then we should be fine, 
> no?

There could be other header files used by user space where we would want 
to switch from slab.h to kmalloc.h in the future. All three header files 
are pretty low level and so we will have frequent includes. I think it is 
safer to have the guard in there.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Pekka J Enberg]

On Tue, 28 Nov 2006, Christoph Lameter wrote:
> There could be other header files used by user space where we would want 
> to switch from slab.h to kmalloc.h in the future.

I think not. An userspace header that depends on <linux/kmalloc.h> would 
be broken by design.

			Pekka

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Pekka Enberg]

On Tue, 28 Nov 2006, Christoph Lameter wrote:
> > There could be other header files used by user space where we would want
> > to switch from slab.h to kmalloc.h in the future.

On 11/28/06, Pekka J Enberg <penberg@cs.helsinki.fi> wrote:
> I think not. An userspace header that depends on <linux/kmalloc.h> would
> be broken by design.

Meaning new ones, of course. The existing ones should be fixed anyway
so I don't see the point of maintaining the mistake done in
<linux/slab.h> long time ago.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Christoph Lameter]

On Tue, 28 Nov 2006, Pekka J Enberg wrote:

> On Tue, 28 Nov 2006, Christoph Lameter wrote:
> > There could be other header files used by user space where we would want 
> > to switch from slab.h to kmalloc.h in the future.
> 
> I think not. An userspace header that depends on <linux/kmalloc.h> would 
> be broken by design.

User space would never use kmalloc.h directly. User space would also not 
use slab.h directly.

A userspace header can use linux/blablabla.h and <linux/blablabla.h> may 
then include <linux/kmalloc.h>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Christoph Lameter]

On Tue, 28 Nov 2006, Pekka Enberg wrote:

> Meaning new ones, of course. The existing ones should be fixed anyway
> so I don't see the point of maintaining the mistake done in
> <linux/slab.h> long time ago.

We may want to switch existing ones that do not need to define their own 
slabs. I doubt that slab.h is used directly by user space. We need to 
cover the indirect use.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Pekka Enberg]

On 11/28/06, Christoph Lameter <clameter@sgi.com> wrote:
> A userspace header can use linux/blablabla.h and <linux/blablabla.h> may
> then include <linux/kmalloc.h>

And that's a broken userspace header all the same. I do see the point
of keeping <linux/slab.h> as is for compatability  but why would we
want to repeat the same mistake in a new interface? If we really do
_need_ to convert existing broken userspace headers to use
<linux/kmalloc.h> we can always fix it locally.

So can we drop the guard clause? Pretty please and sugar on the top.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Christoph Lameter]

On Tue, 28 Nov 2006, Pekka Enberg wrote:

> So can we drop the guard clause? Pretty please and sugar on the top.

Drop it just for slob.h and kmalloc.h? Or also for slab.h?
I think it would be better to be consistent.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Christoph Lameter]

Patch on top of the other to remove the #ifdefs. Also add some annotation
on the other ifdefs.

Signed-off-by: Christoph Lameter <clameter@sgi.com>

Index: linux-2.6.19-rc6-mm1/include/linux/kmalloc.h
===================================================================
--- linux-2.6.19-rc6-mm1.orig/include/linux/kmalloc.h	2006-11-28 15:28:50.000000000 -0800
+++ linux-2.6.19-rc6-mm1/include/linux/kmalloc.h	2006-11-28 15:31:26.000000000 -0800
@@ -5,8 +5,6 @@
 #include <asm/page.h>		/* kmalloc_sizes.h needs PAGE_SIZE */
 #include <asm/cache.h>		/* kmalloc_sizes.h needs L1_CACHE_BYTES */
 
-#ifdef __KERNEL__
-
 /* Size description struct for general caches. */
 struct cache_sizes {
 	size_t		 cs_size;
@@ -201,8 +199,8 @@
 #define kmalloc_node_track_caller(size, flags, node) \
 	__kmalloc_node_track_caller(size, flags, node, \
 				__builtin_return_address(0))
-#endif
-#else
+#endif /* CONFIG_DEBUG_SLAB */
+#else /* CONFIG_NUMA */
 static inline void *kmalloc_node(size_t size, gfp_t flags, int node)
 {
 	return kmalloc(size, flags);
@@ -210,12 +208,10 @@
 
 #define kmalloc_node_track_caller(size, flags, node) \
 	kmalloc_track_caller(size, flags)
-#endif
+#endif /* CONFIG_NUMA */
 
 extern void __init kmem_cache_init(void);
 extern int slab_is_available(void);
 extern int kmem_cache_reap(int);
 
-#endif	/* __KERNEL__ */
-
 #endif	/* _LINUX_KMALLOC_H */
Index: linux-2.6.19-rc6-mm1/include/linux/slob.h
===================================================================
--- linux-2.6.19-rc6-mm1.orig/include/linux/slob.h	2006-11-28 15:28:50.000000000 -0800
+++ linux-2.6.19-rc6-mm1/include/linux/slob.h	2006-11-28 15:31:26.000000000 -0800
@@ -1,8 +1,6 @@
 #ifndef _LINUX_SLOB_H
 #define	_LINUX_SLOB_H
 
-#if	defined(__KERNEL__)
-
 #include <linux/slab.h>
 
 /* SLOB allocator routines */
@@ -42,6 +40,4 @@
 static inline void kmem_set_shrinker(kmem_cache_t *cachep,
 				struct shrinker *shrinker) {}
 
-#endif	/* __KERNEL__ */
-
 #endif	/* _LINUX_SLOB_H */

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Pekka Enberg]

On 11/29/06, Christoph Lameter <clameter@sgi.com> wrote:
> Patch on top of the other to remove the #ifdefs. Also add some annotation
> on the other ifdefs.

Thanks! For both of them:

Acked-by: Pekka Enberg <penberg@cs.helsinki.fi>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Christoph Hellwig]

On Mon, Nov 27, 2006 at 10:33:28PM -0800, Christoph Lameter wrote:
> slab.h really defines multiple APIs. One is the classic slab api
> where one can define a slab cache by specifying exactly how
> the slab has to be generated. This API is not frequently used.
> 
> Another is the kmalloc API. Quite a number of kernel source code files 
> need kmalloc but do not need to generate custom slabs. The kmalloc API 
> also use some funky macros that may be better isolated in an additional .h 
> file in order to ease future cleanup. Make kmalloc.h self contained by 
> adding two extern definitions local to kmalloc and kmalloc_node.
> 
> Then there is the SLOB api mixed in with slab. Take that out and define it 
> in its own header file.

NACK.  This is utterly braindead, easily shown by things like the need
to duplicate the kmem_cache_alloc prototype.

What are you trying to solve with this?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Nick Piggin]

Christoph Hellwig wrote:
> On Mon, Nov 27, 2006 at 10:33:28PM -0800, Christoph Lameter wrote:
> 
>>slab.h really defines multiple APIs. One is the classic slab api
>>where one can define a slab cache by specifying exactly how
>>the slab has to be generated. This API is not frequently used.
>>
>>Another is the kmalloc API. Quite a number of kernel source code files 
>>need kmalloc but do not need to generate custom slabs. The kmalloc API 
>>also use some funky macros that may be better isolated in an additional .h 
>>file in order to ease future cleanup. Make kmalloc.h self contained by 
>>adding two extern definitions local to kmalloc and kmalloc_node.
>>
>>Then there is the SLOB api mixed in with slab. Take that out and define it 
>>in its own header file.
> 
> 
> NACK.  This is utterly braindead, easily shown by things like the need
> to duplicate the kmem_cache_alloc prototype.
> 
> What are you trying to solve with this?

It does seem wrong, I agree. For another thing, there is no "slob API".
Slob is an implementation of the *slab API*.

kmalloc seems OK to be split. But given that it is built on top of the
slab, then it should not be going out of its way to avoid the slab.h
include, as Christoph H points out.

If this whole exercise is to dispense with a few includes, then I'll
second Christoph's nack. This kinds of tricks does not make it easier
to untangle and redesign header dependencies properly in the long term.

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Christoph Lameter]

On Wed, 29 Nov 2006, Pekka Enberg wrote:

> Acked-by: Pekka Enberg <penberg@cs.helsinki.fi>

Thanks. I intend to rediff this against the upcoming mm release given the 
other changes going in right now (2.6.19-rc6-mm2?) and submit at that 
point. I hope I can carry the ack forward from the RFC to the actual 
patch?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Christoph Lameter]

On Wed, 29 Nov 2006, Nick Piggin wrote:

> > NACK.  This is utterly braindead, easily shown by things like the need
> > to duplicate the kmem_cache_alloc prototype.
> > 
> > What are you trying to solve with this?

I am trying to detangle various things in the slab. Its a bit complex.
 
> It does seem wrong, I agree. For another thing, there is no "slob API".
> Slob is an implementation of the *slab API*.

But the definitions vary a lot. Should I try to find the common 
function declarations and keep them together?

> kmalloc seems OK to be split. But given that it is built on top of the
> slab, then it should not be going out of its way to avoid the slab.h
> include, as Christoph H points out.
> 
> If this whole exercise is to dispense with a few includes, then I'll
> second Christoph's nack. This kinds of tricks does not make it easier
> to untangle and redesign header dependencies properly in the long term.

Right now the slab.h is difficult to understand. Separating things out 
will make the .h files small and nicely focused on one thing.

We have some ugly things in kmalloc.h like the include of kmalloc_sizes.h 
and the CACHE definitions. I think those should be separated and then 
hopefully we can fix this up at some point.

Having kmalloc.h separate will also help if we put the definition of 
struct kmem_cache in slab.c. Then the definition will be hidden from the 
simple kmalloc users.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Nick Piggin]

Christoph Lameter wrote:
> On Wed, 29 Nov 2006, Nick Piggin wrote:
> 
> 
>>>NACK.  This is utterly braindead, easily shown by things like the need
>>>to duplicate the kmem_cache_alloc prototype.
>>>
>>>What are you trying to solve with this?
> 
> 
> I am trying to detangle various things in the slab. Its a bit complex.
>  
> 
>>It does seem wrong, I agree. For another thing, there is no "slob API".
>>Slob is an implementation of the *slab API*.
> 
> 
> But the definitions vary a lot. Should I try to find the common 
> function declarations and keep them together?

The point is that it *is the same API*. Having the declarations for the slob
implementation in slob.h, and then including slab.h in slob.h seems completely
backwards.

I don't see that breaking them out gains you very much at all, but if you do
want to, then I'd rather have slob_defs.h and slab_defs.h, then have slab.h
include either one depending on the config.

>>kmalloc seems OK to be split. But given that it is built on top of the
>>slab, then it should not be going out of its way to avoid the slab.h
>>include, as Christoph H points out.
>>
>>If this whole exercise is to dispense with a few includes, then I'll
>>second Christoph's nack. This kinds of tricks does not make it easier
>>to untangle and redesign header dependencies properly in the long term.
> 
> 
> Right now the slab.h is difficult to understand. Separating things out 
> will make the .h files small and nicely focused on one thing.
> 
> We have some ugly things in kmalloc.h like the include of kmalloc_sizes.h 
> and the CACHE definitions. I think those should be separated and then 
> hopefully we can fix this up at some point.
> 
> Having kmalloc.h separate will also help if we put the definition of 
> struct kmem_cache in slab.c. Then the definition will be hidden from the 
> simple kmalloc users.

kmalloc.h uses the slab, and it calls kmem_cache_alloc. How could it be
an improvement to not include slab.h? I don't think hiding a data type
definition has any value, does it?

Other than that, I don't have any problem with moving kmalloc to its own
header.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Christoph Lameter]

On Thu, 30 Nov 2006, Nick Piggin wrote:

> kmalloc.h uses the slab, and it calls kmem_cache_alloc. How could it be
> an improvement to not include slab.h? I don't think hiding a data type
> definition has any value, does it?

Well you argued yesterday (today?) for hiding struct kmem_cache in a 
opaque kmem_cache_t. Now its the other way around?

Maybe its best if I just straighten out slab.h (make a segment for the 
kmalloc material separate from the kmem_cache* functions and try to get 
the special slob definitions out by defining empty function ins slob.c? 

That will work for most of slob but not for the kmalloc portions.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Nick Piggin]

Christoph Lameter wrote:
> On Thu, 30 Nov 2006, Nick Piggin wrote:
> 
> 
>>kmalloc.h uses the slab, and it calls kmem_cache_alloc. How could it be
>>an improvement to not include slab.h? I don't think hiding a data type
>>definition has any value, does it?
> 
> 
> Well you argued yesterday (today?) for hiding struct kmem_cache in a 
> opaque kmem_cache_t. Now its the other way around?

No. I meant that the kmem_cache_t * slab handle that callers get *is*
opaque, as far as they are concerned -- so I wondered what other reasons
there were to remove the typedef.

The enforced hiding of struct kmem_cache is a fun trick, but it is not
something we care about in other parts of the kernel.

> Maybe its best if I just straighten out slab.h (make a segment for the 
> kmalloc material separate from the kmem_cache* functions and try to get 
> the special slob definitions out by defining empty function ins slob.c? 

I don't see the problem with slab/slob. It is not the nicest code, but it
isn't unreadable. We do something very similar with nommu, for (perhaps
not the best!) example.

> That will work for most of slob but not for the kmalloc portions.

But kmalloc seems like one thing that could be split nicely. It would
allow you to get rid of asm/page.h and asm/cache.h from slab.h
(converting callers would be a bigger job).

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Christoph Lameter]

On Thu, 30 Nov 2006, Nick Piggin wrote:

> I don't see the problem with slab/slob. It is not the nicest code, but it
> isn't unreadable. We do something very similar with nommu, for (perhaps
> not the best!) example.

I need some order in there to add another type of slab allocator without 
getting into an umaintainable mess.

> But kmalloc seems like one thing that could be split nicely. It would
> allow you to get rid of asm/page.h and asm/cache.h from slab.h
> (converting callers would be a bigger job).

What callers would need to be converted?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Nick Piggin]

Christoph Lameter wrote:
> On Thu, 30 Nov 2006, Nick Piggin wrote:
> 
> 
>>I don't see the problem with slab/slob. It is not the nicest code, but it
>>isn't unreadable. We do something very similar with nommu, for (perhaps
>>not the best!) example.
> 
> 
> I need some order in there to add another type of slab allocator without 
> getting into an umaintainable mess.

OK, slab_defs.h and slob_defs.h would work, wouldn't it? That seems to be
the standard pattern used when alternatives become too numerous / complex
to be in a single file.

>>But kmalloc seems like one thing that could be split nicely. It would
>>allow you to get rid of asm/page.h and asm/cache.h from slab.h
>>(converting callers would be a bigger job).
> 
> 
> What callers would need to be converted?

When you remove kmalloc.h from slab.h? I guess anyone that includes
slab.h in order to get kmalloc.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Christoph Lameter]

On Thu, 30 Nov 2006, Nick Piggin wrote:

> OK, slab_defs.h and slob_defs.h would work, wouldn't it? That seems to be
> the standard pattern used when alternatives become too numerous / complex
> to be in a single file.

Maybe better define a standard API and provide empty functions for slob?

I think it would be feasable to have all slab allocators work within the 
same kmem_cache_* framework. The kmalloc approaches are all different 
though. So i would need kmalloc_slob and kmalloc_slab?

> > What callers would need to be converted?
> 
> When you remove kmalloc.h from slab.h? I guess anyone that includes
> slab.h in order to get kmalloc.

Well so far I have included kmalloc.h from slab.h for backward 
compatibility reasons in order to avoid that. That allows a gradual 
transition to kmalloc.h for files only needing kmalloc.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Nick Piggin]

Christoph Lameter wrote:
> On Thu, 30 Nov 2006, Nick Piggin wrote:
> 
> 
>>OK, slab_defs.h and slob_defs.h would work, wouldn't it? That seems to be
>>the standard pattern used when alternatives become too numerous / complex
>>to be in a single file.
> 
> 
> Maybe better define a standard API and provide empty functions for slob?

There is a standard API, isn't there? It is the API used by the callers.
Ie. the one in slab.h, before slob came along.

So yes, we *have* to have all allocators using the same kmem_cache_t
framework. I don't see how a different API between slab and slob could
work?

> I think it would be feasable to have all slab allocators work within the 
> same kmem_cache_* framework. The kmalloc approaches are all different 
> though. So i would need kmalloc_slob and kmalloc_slab?

I see, I didn't realise kmalloc was different as well. I guess you could
follow the same approach. Probably don't bother splitting it, and just
move the kmalloc definitions to slab_defs.h / slob_defs.h?

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Christoph Lameter]

On Thu, 30 Nov 2006, Nick Piggin wrote:

> I see, I didn't realise kmalloc was different as well. I guess you could
> follow the same approach. Probably don't bother splitting it, and just
> move the kmalloc definitions to slab_defs.h / slob_defs.h?

kmalloc implementation are very different.

We could segment slab.h into a a part for the kmem_cache_* API. All slab 
allocators need to provide that API and if they do not need a certain 
function will have to define a stub in a c file.

Then we will have a portion like this that redirects to the allocator
specific kmalloc implementation:

#ifdef CONFIG_SLOB
#include <linux/kmalloc_slob.h>
#else
#ifdef CONFIG_SLUB
#include <linux/kmalloc_slub.h>
#else
#include <linux/kmalloc_slab.h>
#endif
#endif

Following this part generic kmalloc related definitions kzalloc kcalloc 
etc.

?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Nick Piggin]

Christoph Lameter wrote:
> On Thu, 30 Nov 2006, Nick Piggin wrote:
> 
> 
>>I see, I didn't realise kmalloc was different as well. I guess you could
>>follow the same approach. Probably don't bother splitting it, and just
>>move the kmalloc definitions to slab_defs.h / slob_defs.h?
> 
> 
> kmalloc implementation are very different.
> 
> We could segment slab.h into a a part for the kmem_cache_* API. All slab 
> allocators need to provide that API and if they do not need a certain 
> function will have to define a stub in a c file.
> 
> Then we will have a portion like this that redirects to the allocator
> specific kmalloc implementation:

I'd rather not do the stub thing, and just split out slab_defs / slob_defs
slub_defs. Then you don't have to create the specific kmalloc headers either.

> 
> #ifdef CONFIG_SLOB
> #include <linux/kmalloc_slob.h>
> #else
> #ifdef CONFIG_SLUB
> #include <linux/kmalloc_slub.h>
> #else
> #include <linux/kmalloc_slab.h>
> #endif
> #endif

elseifdef works here :)

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC] Extract kmalloc.h and slob.h from slab.h

[Pekka Enberg]

On 11/30/06, Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> The point is that it *is the same API*. Having the declarations for the slob
> implementation in slob.h, and then including slab.h in slob.h seems completely
> backwards.

Agreed that it would be cleaner if we, for example, had <linux/kmem.h>
that included either <linux/slab.h> or <linux/slob.h> depending on
config. However, Christoph's split does make sense, the slob
_implementation_ is completely different in the header. It doesn't
have any of the inlining tricks we do for slab.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>