From: Christoph Lameter <cl@linux-foundation.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: Dave Hansen <dave@linux.vnet.ibm.com>,
David Rientjes <rientjes@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@suse.de>,
Nick Piggin <npiggin@suse.de>, Mel Gorman <mel@csn.ul.ie>,
Peter Ziljstra <a.p.ziljstra@chello.nl>,
San Mehat <san@android.com>, Arve Hj?nnev?g <arve@android.com>,
linux-kernel@vger.kernel.org
Subject: Re: Misleading OOM messages
Date: Fri, 15 May 2009 13:57:53 -0400 (EDT) [thread overview]
Message-ID: <alpine.DEB.1.10.0905151346550.26559@qirst.com> (raw)
In-Reply-To: <20090514213403.GB14741@elf.ucw.cz>
On Thu, 14 May 2009, Pavel Machek wrote:
> > "No available memory" still suggests that plugging in more memory is the
> > right solution.
>
> And... on correctly working kernel, it is, right?
Nope. Usually something else is amiss if OOM occurs.
> If you have no swap space and too many applications, you plug more
> memory. (Or invent some swap).
Thats not a usual configuration. OOM there also depends on various OS
knobs. The failure occurred because application did anonymous allocations
and you did not give the OS a way to effectively push these pages out to
disk. Thus it was not able to reclaim memory.
> If you misconfigured cgroups, you give more memory to them.
If you do not have enough memory in a cgroup then your application should
slow down (because of page evictions) but the system should not OOM.
Are cgroups broken or why are you getting OOMs when using them?
> If your applications mlocked 900MB and you have 1GB, you need to plug
> more memory.
IMHO the mlocking is the issue. There are safeguards (ulimit) to prevent
this. Again a typical misconfiguration that requires disabling safeguards.
If you increase memory then more memory is likely going to be mlocked by
whoever went crazy with mlocking in the first place.
> So... when is plugging more memory _not_ valid answer? AFAICT it is
> when it is some kernel problem, resulting in memory not being
> reclaimed fast enough....
Reclaim failures occur typically because memory is not reclaimable due to
mlocking, memory allocation in a context where we cannot perform
effective reclaim (no disk access, atomic context) (device
drivers are prone to that), or when asking for higher order pages and the
defrag logic cannot satisfy your request.
Then there is the issue on 32 bit platforms where certain kernel
allocations must occur in the memory zone under 1G. If you add more memory
then less memory is available e under !G because the kernel needs to
allocate more metadata to manage more memory. Thus you OOM faster.
So I thin that an OOM is about misconfigurations or a kernel bug. If the
application needs more memory then the pageing mechanism of the OS should
create more virtual memory for the process.
next prev parent reply other threads:[~2009-05-15 18:29 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-10 22:07 [patch 01/11 -mmotm] lowmemorykiller: Only iterate over process list when needed David Rientjes
2009-05-10 22:07 ` [patch 02/11 -mmotm] lowmemorykiller: Don't count free space unless it meets the specified limit by itself David Rientjes
2009-05-12 9:23 ` Mel Gorman
2009-05-13 0:27 ` Arve Hjønnevåg
2009-05-13 9:42 ` Mel Gorman
2009-05-14 23:25 ` Arve Hjønnevåg
2009-05-15 9:18 ` Mel Gorman
2009-05-10 22:07 ` [patch 03/11 -mmotm] oom: cleanup android low memory killer David Rientjes
2009-05-10 22:07 ` [patch 04/11 -mmotm] oom: fix possible android low memory killer NULL pointer David Rientjes
2009-05-10 22:07 ` [patch 05/11 -mmotm] oom: fix possible oom_dump_tasks " David Rientjes
2009-05-11 21:11 ` Andrew Morton
2009-05-11 21:28 ` David Rientjes
2009-05-11 21:41 ` Greg KH
2009-05-11 22:05 ` David Rientjes
2009-05-12 9:38 ` Mel Gorman
2009-05-10 22:07 ` [patch 06/11 -mmotm] oom: move oom_adj value from task_struct to mm_struct David Rientjes
2009-05-11 0:17 ` KOSAKI Motohiro
2009-05-11 0:26 ` David Rientjes
2009-05-11 1:47 ` KOSAKI Motohiro
2009-05-11 8:43 ` David Rientjes
2009-05-11 21:19 ` Andrew Morton
2009-05-12 9:56 ` Mel Gorman
2009-05-10 22:07 ` [patch 07/11 -mmotm] oom: prevent possible OOM_DISABLE livelock David Rientjes
2009-05-11 21:22 ` Andrew Morton
2009-05-10 22:07 ` [patch 08/11 -mmotm] oom: invoke oom killer for __GFP_NOFAIL David Rientjes
2009-05-10 23:59 ` KOSAKI Motohiro
2009-05-11 0:24 ` David Rientjes
2009-05-11 1:45 ` KOSAKI Motohiro
2009-05-11 7:40 ` Minchan Kim
2009-05-11 8:49 ` David Rientjes
2009-05-11 11:23 ` Minchan Kim
2009-05-11 8:45 ` David Rientjes
2009-05-11 16:03 ` Dave Hansen
2009-05-11 19:09 ` David Rientjes
2009-05-11 19:45 ` Dave Hansen
2009-05-11 20:21 ` David Rientjes
2009-05-11 21:29 ` Andrew Morton
2009-05-11 21:45 ` David Rientjes
2009-05-11 22:11 ` Andrew Morton
2009-05-11 22:31 ` David Rientjes
2009-05-11 22:46 ` Andrew Morton
2009-05-11 23:00 ` David Rientjes
2009-05-11 23:14 ` Andrew Morton
2009-05-11 23:37 ` David Rientjes
2009-05-12 5:39 ` Peter Zijlstra
2009-05-12 11:36 ` KOSAKI Motohiro
2009-05-12 10:05 ` Mel Gorman
2009-05-10 22:07 ` [patch 09/11 -mmotm] oom: return vm size of oom killed task David Rientjes
2009-05-11 21:36 ` Andrew Morton
2009-05-10 22:07 ` [patch 10/11 -mmotm] oom: avoid oom kill if no interruptible tasks David Rientjes
2009-05-11 21:39 ` Andrew Morton
2009-05-11 23:08 ` David Rientjes
2009-05-10 22:07 ` [patch 11/11 -mmotm] oom: fail allocations if oom killer can't free memory David Rientjes
2009-05-12 21:14 ` Misleading OOM messages Christoph Lameter
2009-05-14 9:29 ` Pavel Machek
2009-05-14 19:46 ` Christoph Lameter
2009-05-14 20:38 ` Dave Hansen
2009-05-14 20:49 ` Christoph Lameter
2009-05-14 20:49 ` David Rientjes
2009-05-14 21:05 ` Dave Hansen
2009-05-14 21:12 ` David Rientjes
2009-05-14 21:30 ` Christoph Lameter
2009-05-14 21:34 ` Pavel Machek
2009-05-14 21:41 ` Dave Hansen
2009-05-15 13:05 ` Pavel Machek
2009-05-15 17:59 ` Christoph Lameter
2009-05-15 18:22 ` Dave Hansen
2009-05-15 19:29 ` Christoph Lameter
2009-05-15 20:02 ` Pavel Machek
2009-05-15 21:15 ` Christoph Lameter
2009-05-19 20:39 ` Pavel Machek
2009-05-22 13:53 ` Christoph Lameter
2009-05-22 14:17 ` Warn when we run out of swap space (was Re: Misleading OOM messages) Christoph Lameter
2009-05-22 14:56 ` Pavel Machek
2009-05-22 19:01 ` Misleading OOM messages Christoph Lameter
2009-05-22 19:40 ` Randy Dunlap
2009-05-22 19:44 ` Christoph Lameter
2009-05-22 21:45 ` Alan Cox
2009-05-22 21:43 ` Alan Cox
2009-05-15 17:57 ` Christoph Lameter [this message]
2009-05-15 18:15 ` Dave Hansen
2009-05-15 18:19 ` Balbir Singh
2009-05-15 19:26 ` Christoph Lameter
2009-05-15 20:31 ` Balbir Singh
2009-05-18 14:34 ` Christoph Lameter
2009-05-18 15:45 ` Balbir Singh
2009-05-14 21:37 ` Dave Hansen
2009-05-14 22:00 ` David Rientjes
2009-05-15 17:58 ` Christoph Lameter
2009-05-15 18:23 ` Dave Hansen
2009-05-15 18:57 ` Balbir Singh
2009-05-15 19:37 ` David Rientjes
2009-05-14 20:56 ` Pavel Machek
2009-05-12 9:09 ` [patch 01/11 -mmotm] lowmemorykiller: Only iterate over process list when needed Mel Gorman
2009-05-13 0:43 ` Arve Hjønnevåg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.1.10.0905151346550.26559@qirst.com \
--to=cl@linux-foundation.org \
--cc=a.p.ziljstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=arve@android.com \
--cc=dave@linux.vnet.ibm.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=npiggin@suse.de \
--cc=pavel@ucw.cz \
--cc=rientjes@google.com \
--cc=san@android.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®