Skip to contentSkip to conversation

Show slab memory usage on OOM and SysRq-M (v3)

PATCH In review Pavel Emelianov 3 participants 3 messages Apr 18, 2007 – Apr 23, 2007

Subsystems (4)
Memory management Char and misc drivers Slab allocator Memory management - OOM killer
lore
Share & tools
lore

Pavel Emelianov

author
#0 lore raw

PATCH 1/1 Show slab memory usage on OOM and SysRq-M (v3)

The out_of_memory() function and SysRq-M handler call show_mem() to show the current memory usage state.

This is also helpful to see which slabs are the largest in the system.

Thanks Pekka for good idea of how to make it better.

The nr_pages is stored on kmem_list3 because:

1. as Eric pointed out, we do not want to defeat NUMA optimizations;
2. we do not need for additional LOCK-ed operation on altering this field - l3->list_lock is already taken where needed.

Made naming more descriptive according to Dave.

Signed-off-by Pavel Emelianov <[email protected]>
Signed-off-by Kirill Korotaev <[email protected]>
Acked-by Pekka Enberg <[email protected]>
Cc Eric Dumazet <[email protected]>
Cc Dave Hansen <[email protected]>

---

drivers/char/sysrq.c +1 -0
index 39cc318..7c27647 100644
@@ -234,6 +234,7 @@ static struct sysrq_key_op sysrq_showsta
 static void sysrq_handle_showmem(int key, struct tty_struct *tty)
 {
 	show_mem();
+	show_slabs();
 }
 static struct sysrq_key_op sysrq_showmem_op = {
 	.handler	= sysrq_handle_showmem,
include/linux/slab.h +6 -0
index 67425c2..1e2919d 100644
@@ -170,6 +170,12 @@ static inline void *kzalloc(size_t size,
 }
 #endif
 
+#ifdef CONFIG_SLAB
+extern void show_slabs(void);
+#else
+#define show_slabs(void)	do { } while (0)
+#endif
+
 #ifndef CONFIG_NUMA
 static inline void *kmalloc_node(size_t size, gfp_t flags, int node)
 {
mm/oom_kill.c +1 -0
index 4bdc7c0..aefdd06 100644
@@ -409,6 +409,7 @@ void out_of_memory(struct zonelist *zone
 			current->comm, gfp_mask, order, current->oomkilladj);
 		dump_stack();
 		show_mem();
+		show_slabs();
 	}
 
 	cpuset_lock();
mm/slab.c +76 -0

137 lines not on this page · raw message

maintainer
#1 lore raw
Quoted 16 lines · On Wed, 18 Apr 2007 11:13:01 +0400 Pavel Emelianov <[email protected]> wrote:

The out_of_memory() function and SysRq-M handler call show_mem() to show the current memory usage state.

This is also helpful to see which slabs are the largest in the system.

Thanks Pekka for good idea of how to make it better.

The nr_pages is stored on kmem_list3 because:

1. as Eric pointed out, we do not want to defeat NUMA optimizations;
2. we do not need for additional LOCK-ed operation on altering this field - l3->list_lock is already taken where needed.

Quoted 8 lines

Made naming more descriptive according to Dave.

Signed-off-by Pavel Emelianov <[email protected]>
Signed-off-by Kirill Korotaev <[email protected]>
Acked-by Pekka Enberg <[email protected]>
Cc Eric Dumazet <[email protected]>
Cc Dave Hansen <[email protected]>

This is rather a lot of new code and even new locking.

Any time we actually need this what-the-heck-is-happening-in-slab info, the reporter is able to work out the problem via /proc/slabinfo. Either by taking a look in there before the system dies completely, or by looking in there after the oom-killing.

#2 lore raw
Quoted 28 lines · Andrew Morton
Quoted 16 lines · On Wed, 18 Apr 2007 11:13:01 +0400 Pavel Emelianov <[email protected]> wrote:

The out_of_memory() function and SysRq-M handler call show_mem() to show the current memory usage state.

This is also helpful to see which slabs are the largest in the system.

Thanks Pekka for good idea of how to make it better.

The nr_pages is stored on kmem_list3 because:

1. as Eric pointed out, we do not want to defeat NUMA optimizations;
2. we do not need for additional LOCK-ed operation on altering this field - l3->list_lock is already taken where needed.

Quoted 8 lines

Made naming more descriptive according to Dave.

Signed-off-by Pavel Emelianov <[email protected]>
Signed-off-by Kirill Korotaev <[email protected]>
Acked-by Pekka Enberg <[email protected]>
Cc Eric Dumazet <[email protected]>
Cc Dave Hansen <[email protected]>
Quoted 6 lines

This is rather a lot of new code and even new locking.

Any time we actually need this what-the-heck-is-happening-in-slab info, the reporter is able to work out the problem via /proc/slabinfo. Either by taking a look in there before the system dies completely, or by looking in there after the oom-killing.

the reality looks a bit differently (at least on machines overcommited with containers):
1. OOM can be unable to free enough memory for the system to do some
real progress in some real-life situations. So you can't login and check.
2. People do not tend to monitor the logs and check the issue immeadeately when it happened. So having an information collected from the kernel is really helpfull. show_mem() does exactly the same on OOM.

So it is up to you, but I would suggest to commit. Locking introduced here is simple and overhead-free on fast paths.

Thanks,
Kirill