linux-kernel - Re: OOM kernel behaviour

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]

Message-ID: <4B151862.9020201@cybus.co.uk>
Date:	Tue, 01 Dec 2009 13:21:38 +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 01/12/09 09:57 Jonathan Miles said the following:

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

And here's another (attached), with a slightly different initial code
path, where hald has caused the OOM killer to be invoked even though
(again) there was ~1.3GB out of 2GB used by the page-cache.

[66568.252937] Call Trace:
[66568.252963]  [<c01b5a0f>] oom_kill_process+0x9f/0x250
[66568.252981]  [<c01b601e>] ? select_bad_process+0xbe/0xf0
[66568.252989]  [<c01b60a1>] __out_of_memory+0x51/0xa0
[66568.252997]  [<c01b6143>] out_of_memory+0x53/0xb0
[66568.253045]  [<c01b83fe>] __alloc_pages_slowpath+0x42e/0x480
[66568.253055]  [<c01b855f>] __alloc_pages_nodemask+0x10f/0x120
[66568.253077]  [<c01ca076>] do_anonymous_page+0x66/0x200
...

Hopefully I'll get some time to RTFS, but at the moment I'm trying to
understand whether or not this is *intended* behaviour. When there's no
swap available, should the kernel be calling the OOM killer instead of
trying to reclaim memory from buffers/cache?

Thanks,

-- 
Jonathan Miles <jon@...us.co.uk>
http://www.linkedin.com/in/jonmiles


View attachment "OOM2.txt" of type "text/plain" (3695 bytes)