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:	Tue, 01 Dec 2009 09:57:54 +0000
From:	Jonathan Miles <jon@...us.co.uk>
To:	Christoph Lameter <cl@...ux-foundation.org>
CC:	linux-kernel@...r.kernel.org
Subject: Re: OOM kernel behaviour

On 30/11/09 18:57 Christoph Lameter said the following:
> On Mon, 30 Nov 2009, Jonathan Miles wrote:
> 
>> I'm running kernel 2.6.31.
> 
> Are you using a 32 bit kernel?

Yep, it's the stock 32-bit x86 kernel from Ubuntu...

  2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686
    GNU/Linux

... but I could compile in a mainline version, if anyone thinks it would
make a difference. I suspect this is a general issue, though.

> Disabling swap means that the kernel cannot swap out anonymous pages. Thus
> the chance of OOMs conditions is increased.

Yep, that's what I intended. I want to tune my workstation so that it
doesn't need to use swap. With my workload you can assume that nearly
all processes are loaded for a reason and that at some point I want to
use any one of them *now*.

> In order to find the reason for the OOM (which has not much to do with
> memory, the kernel has been unable to reclaim memmory for some reason)
> you need to look at the debug output that the kernel generates.

I've attached a good example which shows Xorg invoking the OOM killer
when the page-cache is using ~1.3GB out of 2GB. My understanding from
reading linux-mm.org is that the kernel actually prefers to swap than
reclaim from the page-cache... is this accurate? However, what if there
is no swap, or it's configured not to use it? Should the kernel then try
to reclaim instead?

Thanks,

Jon

View attachment "OOM1.txt" of type "text/plain" (4255 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ