quieten OOM killer noise

We now print statistics when invoking the OOM killer, however this information is not rate limited and you can get into situations where the console is continually spammed.

For example, when a task is exiting the OOM killer will simply return (waiting for that task to exit and clear up memory). If the VM continually calls back into the OOM killer we get thousands of copies of show_mem() on the console.

Use printk_ratelimit() to quieten it.

Index: foobar2/mm/oom_kill.c
===================================================================
@@ -258,9 +258,11 @@
 	struct mm_struct *mm = NULL;
 	task_t * p;
 
-	printk("oom-killer: gfp_mask=0x%x\n", gfp_mask);
-	/* print memory stats */
-	show_mem();
+	if (printk_ratelimit()) {
+		printk("oom-killer: gfp_mask=0x%x\n", gfp_mask);
+		/* print memory stats */
+		show_mem();
+	}
 
 	read_lock(&tasklist_lock);
 retry:

Why not just remove the printk's when DEBUG_KERNEL is off. The problem that I've found is that the latency in the system sky rockets when OOM triggers. It's due to the excessive printk usage.

I'm sure it's not ifdef'ed for a reason , but it would be nice to have an easy way to silence it.

Daniel

Hi,

We've had customer situations where that information would have been very useful. Also DEBUG_KERNEL is enabled on some distros so it wouldnt help there.

Id suggest adding a printk level to the printks in mm/oom-kill.c and using /proc/sys/kernel/printk to silence them.

Anton

The latency problem stems from running printk, so I'm not sure that silencing them in this way would help . We could add a debug option just for this ? I'm sure OOM has other debugging output . CONFIG_OOM, and CONFIG_DEBUG_OOM .

Daniel

Anton Blanchard wrote: {
Id suggest adding a printk level to the printks in mm/oom-kill.c and using /proc/sys/kernel/printk to silence them.
}

Good option!

Also, why is OOM-killer needed when overcommit is disabled?

Al

I haven't looked closely, but when I provoked the oom killer last week a few times while working on something else, I did notice that the printk's that came out were a page or two, per kill. Apparently it is the arch-specific show_mem() routine that was so verbose - this was on an ia64 SN2.

Do we really need that lengthy an oom printk? If the other arch's tend to be a little more terse, then I guess you could catalog my complaint as a "personal problem" or at least an "arch problem."

In support of this ratelimiting, the other call from main line kernel code to show_mem(), after the __alloc_pages() message:

	 page allocation failure. order:%d, mode:0x%x

is already ratelimited. Seems like a good idea.

                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <[email protected]> 1.925.600.0401

Can anyone suggest me how to get the threadId using 2.6.x kernels. pthread_self() does not work and returns some -ve integer.

thanks
rvk

NAME
pthread_self - get the calling thread ID

SYNOPSIS

       #include <pthread.h>

       pthread_t pthread_self(void);

DESCRIPTION
The pthread_self() function shall return the thread ID of the
calling thread.

pthread_self() works just fine for me. But... what makes you think a "negative" value is a failure? What interpretation are you giving to thread ID that negative woudl be wrong? A pthreads thread ID is just a cookie you only can use to give back to the pthread library functions in places where it's needed...

Hi,

Let me guess: You are looking for get_tid() :-)

Bene

You are right Ben....gettid() will do for me. Previously for 2.4.x (2.4.18)thread libraries I normally was using pthread_self().

Raghu