Skip to contentSkip to conversation

: leak tracking for kmalloc node

PATCH In review Christoph Hellwig 3 participants 7 messages Oct 30, 2006 – Nov 8, 2006

Subsystems (2)
Memory management Slab allocator
lore
Share & tools
lore

Christoph Hellwig

author
#0 lore raw

PATCH 1/3 : leak tracking for kmalloc node

If we want to use the node-aware kmalloc in __alloc_skb we need the tracker is responsible for leak tracking magic for it. This patch implements it. The code is far too ugly for my taste, but it's doing exactly what the regular kmalloc is doing and thus follows it's style.

Signed-off-by Christoph Hellwig <[email protected]>
include/linux/slab.h +23 -0
Index: linux-2.6/include/linux/slab.h
===================================================================
@@ -236,7 +236,25 @@
 	}
 	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(kmem_cache_t *cachep, gfp_t flags, int node)
 {
 	return kmem_cache_alloc(cachep, flags);

@@ -245,6 +263,9 @@
 {
 	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));

@@ -283,6 +304,8 @@
 #define kzalloc(s, f) __kzalloc(s, f)
 #define kmalloc_track_caller kmalloc
 
+#define kmalloc_node_track_caller kmalloc_node
+
 #endif /* CONFIG_SLOB */
 
 /* System wide caches */
mm/slab.c +42 -14

119 lines not on this page · raw message

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

#1 lore raw

Hi,

Quoted 5 lines · Christoph Hellwig

If we want to use the node-aware kmalloc in __alloc_skb we need the tracker is responsible for leak tracking magic for it. This patch implements it. The code is far too ugly for my taste, but it's doing exactly what the regular kmalloc is doing and thus follows it's style.

Yeah, the allocation paths are ugly. If only someone with NUMA machine could give this a shot so we can get it merged:

http://marc.theaimsgroup.com/?l=linux-kernel&m=115952740803511&w=2

Should clean up NUMA kmalloc tracking too.

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

author
#2 lore raw
Quoted 7 lines · Pekka Enberg
Quoted 5 lines · Christoph Hellwig

If we want to use the node-aware kmalloc in __alloc_skb we need the tracker is responsible for leak tracking magic for it. This patch implements it. The code is far too ugly for my taste, but it's doing exactly what the regular kmalloc is doing and thus follows it's style.

Quoted 6 lines

Yeah, the allocation paths are ugly. If only someone with NUMA machine could give this a shot so we can get it merged:

http://marc.theaimsgroup.com/?l=linux-kernel&m=115952740803511&w=2

Should clean up NUMA kmalloc tracking too.

I'll give this a try on a small numa machine (CELL with 2 nodes).

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

#3 lore raw
In reply to Pekka Enberg
Quoted 9 lines · Pekka Enberg

Hi,

Quoted 5 lines · Christoph Hellwig

If we want to use the node-aware kmalloc in __alloc_skb we need the tracker is responsible for leak tracking magic for it. This patch implements it. The code is far too ugly for my taste, but it's doing exactly what the regular kmalloc is doing and thus follows it's style.

Quoted 6 lines

Yeah, the allocation paths are ugly. If only someone with NUMA machine could give this a shot so we can get it merged:

http://marc.theaimsgroup.com/?l=linux-kernel&m=115952740803511&w=2

Should clean up NUMA kmalloc tracking too.

I can give this a test, what is it based on...

-apw

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

#5 lore raw
In reply to Andy Whitcroft

Hi Andy,

Quoted 1 line · Andy Whitcroft

I can give this a test, what is it based on...

While you are at it, could you please give Christoph's NUMA leak tracking patch a spin too? I have included a rediffed version of it on top of my alloc path cleanup patch. Thanks!

Pekka

[PATCH] slab: leak tracking for kmalloc node

From: Christoph Hellwig <[email protected]>

If we want to use the node-aware kmalloc in __alloc_skb we need the tracker is responsible for leak tracking magic for it. This patch implements it.

Signed-off-by Christoph Hellwig <[email protected]>
Signed-off-by Pekka Enberg <[email protected]>

---

 include/linux/slab.h |   23 +++++++++++++++++++++++
 mm/slab.c            |   28 +++++++++++++++++++++++++---
 2 files changed, 48 insertions(+), 3 deletions(-)
include/linux/slab.h +23 -0
Index: 2.6/include/linux/slab.h
===================================================================
@@ -236,7 +236,25 @@ found:
 	}
 	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(kmem_cache_t *cachep, gfp_t flags, int node)
 {
 	return kmem_cache_alloc(cachep, flags);

@@ -245,6 +263,9 @@ static inline void *kmalloc_node(size_t 
 {
 	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));

@@ -283,6 +304,8 @@ static inline void *kcalloc(size_t n, si
 #define kzalloc(s, f) __kzalloc(s, f)
 #define kmalloc_track_caller kmalloc
 
+#define kmalloc_node_track_caller kmalloc_node
+
 #endif /* CONFIG_SLOB */
 
 /* System wide caches */
mm/slab.c +25 -3
Index: 2.6/mm/slab.c
===================================================================
@@ -3478,17 +3478,39 @@ void *kmem_cache_alloc_node(struct kmem_
 }
 EXPORT_SYMBOL(kmem_cache_alloc_node);
 
-void *__kmalloc_node(size_t size, gfp_t flags, int node)
+static __always_inline void *__do_kmalloc_node(size_t size, gfp_t flags,
+					       int node, void *caller)
 {
 	struct kmem_cache *cachep;
 
 	cachep = kmem_find_general_cachep(size, flags);
 	if (unlikely(cachep == NULL))
 		return NULL;
-	return kmem_cache_alloc_node(cachep, flags, node);
+	return cache_alloc(cachep, flags, node, caller);
+}
+
+#ifdef CONFIG_DEBUG_SLAB
+void *__kmalloc_node(size_t size, gfp_t flags, int node)
+{
+	return __do_kmalloc_node(size, flags, node,
+			__builtin_return_address(0));
 }
 EXPORT_SYMBOL(__kmalloc_node);
-#endif
+
+void *__kmalloc_node_track_caller(size_t size, gfp_t flags,
+		int node, void *caller)
+{
+	return __do_kmalloc_node(size, flags, node, caller);
+}
+EXPORT_SYMBOL(__kmalloc_node_track_caller);
+#else
+void *__kmalloc_node(size_t size, gfp_t flags, int node)
+{
+	return __do_kmalloc_node(size, flags, node, NULL);
+}
+EXPORT_SYMBOL(__kmalloc_node);
+#endif /* CONFIG_DEBUG_SLAB */
+#endif /* CONFIG_NUMA */
 
 /**
  * __do_kmalloc - allocate memory

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

#6 lore raw
Quoted 8 lines · Pekka J Enberg

Hi Andy,

Quoted 1 line · Andy Whitcroft

I can give this a test, what is it based on...

While you are at it, could you please give Christoph's NUMA leak tracking patch a spin too? I have included a rediffed version of it on top of my alloc path cleanup patch. Thanks!

Ok, submitted both of these for testing on a variety of architectures, mostly NUMA's will let you know what happens. I'd expect the results on TKO by tommorrow; someone has just dropped -rc5 and -rc5-mm1 on us :).

-apw

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