Re: [PATCH] quieten OOM killer noise

Re: [PATCH] quieten OOM killer noise

[Daniel Walker]

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

On Sun, 24 Jul 2005, Anton Blanchard wrote:

> 
> 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.
> 
> Signed-off-by: Anton Blanchard <anton@samba.org>
> 
> Index: foobar2/mm/oom_kill.c
> ===================================================================
> --- foobar2.orig/mm/oom_kill.c	2005-07-02 15:56:13.000000000 +1000
> +++ foobar2/mm/oom_kill.c	2005-07-04 01:38:59.474324542 +1000
> @@ -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:
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@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: [PATCH] quieten OOM killer noise

[Anton Blanchard]

Hi,

> 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.

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

Re: [PATCH] quieten OOM killer noise

[Daniel Walker]

On Mon, 4 Jul 2005, Anton Blanchard wrote:

> 
> Hi,
> 
> > 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.
> 
> 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.

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  

RE: [PATCH] quieten OOM killer noise

[Al Boldi]

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

Thread_Id

[RVK]

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

Re: Thread_Id

[Arjan van de Ven]

On Tue, 2005-07-05 at 17:45 +0530, RVK wrote:
> Can anyone suggest me how to get the threadId using 2.6.x kernels. 
> pthread_self() does not work and returns some -ve integer.

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...

Re: Thread_Id

[Benedikt Spranger]

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

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

Bene

Re: [PATCH] quieten OOM killer noise

[Paul Jackson]

Anton wrote:
> We've had customer situations where that information would have been
> very useful.

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 <pj@sgi.com> 1.925.600.0401

Re: Thread_Id

[RVK]

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

Benedikt Spranger wrote:

>Hi,
>  
>
>>Can anyone suggest me how to get the threadId using 2.6.x kernels.
>>pthread_self() does not work and returns some -ve integer.
>>    
>>
>
>Let me guess: You are looking for get_tid() :-)
>
>Bene
>.
>
>  
>

[PATCH] quieten OOM killer noise

[Anton Blanchard]

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.

Signed-off-by: Anton Blanchard <anton@samba.org>

Index: foobar2/mm/oom_kill.c
===================================================================
--- foobar2.orig/mm/oom_kill.c	2005-07-02 15:56:13.000000000 +1000
+++ foobar2/mm/oom_kill.c	2005-07-04 01:38:59.474324542 +1000
@@ -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: