lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 11 Aug 2011 01:02:04 -0700 (PDT)
From:	Mahmood Naderan <nt_mahmood@...oo.com>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Randy Dunlap <rdunlap@...otime.net>,
	"\"\"\"linux-kernel@...r.kernel.org\"\"\"" 
	<linux-kernel@...r.kernel.org>,
	"\"\"linux-mm@...ck.org\"\"" <linux-mm@...ck.org>
Subject: Re: running of out memory => kernel crash

>Despite it's name, kswapd is still active, it's trying to reclaim memory 
>to prevent having to kill a process as the last resort.
 
I understand what you said, but I did two scenarios:
1- I wrote a simple C++ program that "new" a lot of pointers.
   for ( int i = 0; i < n; i++ ) {
     for ( int j = 0; j < n; j++ ) {
       for ( int k = 0; k < n; k++ ) {
         for ( int l = 0; l < n; l++ ) {
           double *ptr1 = new double[n*i];
           double *ptr2 = new double[n*j];
     }}}}

When I run the program, it ill eat the memory and when it reaches the
maximum ram, it get killed and I saw  message on terminal:

mahmood@vpc:~$ ./leak
Killed

for this scenario, there is no kswapd process running. As it eats the memory
suddenly it get killed.

2- There is 300MB ram. I opened an application saw that
free space reduced to 100MB, then another application reduced the free
space to 30MB. Another application reduced to 4MB. Now the "kswapd"
is running with a lot of disk activity and tries to keep free space at 4MB.
In this scenario, No application is killed.

The question is why in one scenario, the application is killed and in one
scenario, kswapd is running.

I think in the first scenario, the oom_score is calculated more rapidly 
than the second, so immediately is get killed. So kswapd has no chance 
to run because application is killed sooner. In the second scenario, 
kswapd has time to run first. So it will try to free some spaces. However 
since the disk activity is very high, the response time is very high
so the oom_score is calculated lately than first scenario.

Is my understandings correct?


>If /proc/sys/vm/panic_on_oom is not set, as previously mentioned, then 
>we'll need the kernel log to diagnose this further.
I checked that and it is 0. I am trying to reproduce the problem to get some logs


// Naderan *Mahmood;


----- Original Message -----
From: David Rientjes <rientjes@...gle.com>
To: Mahmood Naderan <nt_mahmood@...oo.com>
Cc: Randy Dunlap <rdunlap@...otime.net>; """linux-kernel@...r.kernel.org""" <linux-kernel@...r.kernel.org>; ""linux-mm@...ck.org"" <linux-mm@...ck.org>
Sent: Thursday, August 11, 2011 11:43 AM
Subject: Re: running of out memory => kernel crash

On Thu, 11 Aug 2011, Mahmood Naderan wrote:

> >The default behavior is to kill all eligible and unkillable threads until 
> >there are none left to sacrifice (i.e. all kthreads and OOM_DISABLE).
>  
> In a simple test with virtualbox, I reduced the amount of ram to 300MB. 
> Then I ran "swapoff -a" and opened some applications. I noticed that the free
> spaces is kept around 2-3MB and "kswapd" is running. Also I saw that disk
> activity was very high. 
> That mean although "swap" partition is turned off, "kswapd" was trying to do
> something. I wonder how that behavior can be explained?
> 

Despite it's name, kswapd is still active, it's trying to reclaim memory 
to prevent having to kill a process as the last resort.

If /proc/sys/vm/panic_on_oom is not set, as previously mentioned, then 
we'll need the kernel log to diagnose this further.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists