From: Randy Dunlap <randy.dunlap@oracle.com>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: Pavel Machek <pavel@ucw.cz>,
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, 22 May 2009 12:40:23 -0700 [thread overview]
Message-ID: <4A16FFA7.5010005@oracle.com> (raw)
In-Reply-To: <alpine.DEB.1.10.0905221500390.5204@qirst.com>
Christoph Lameter wrote:
> Subject: Remove misleading kernel log entries about "Out of Memory" conditions
>
> What we traditionally call an "out of memory" failure is mostly not really
> related to having enough physical memory. "out of memory" occurs when the
> memory reclaim attempts fail to provide enough memory for an allocation.
>
> Typically there is a misconfiguration or kernel bug that is at the root
> of an out of memory issue. The message suggests that the machine does
> not have enough memory which is not true.
>
> People have done strange things as a result of these messages. Some
> put more physical memory into their machines others limit the memory
> use of their applications with ulimit. Having a clear message avoids
> these reactions.
>
> So change the messages to describe what actually went wrong.
>
> Signed-off-by: Christoph Lameter <cl@linux-foundation.org>
>
> ---
> mm/oom_kill.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> Index: linux-2.6/mm/oom_kill.c
> ===================================================================
> --- linux-2.6.orig/mm/oom_kill.c 2009-05-12 12:37:52.000000000 -0500
> +++ linux-2.6/mm/oom_kill.c 2009-05-12 12:44:36.000000000 -0500
> @@ -387,7 +387,7 @@ static int oom_kill_process(struct task_
> struct task_struct *c;
>
> if (printk_ratelimit()) {
> - printk(KERN_WARNING "%s invoked oom-killer: "
> + printk(KERN_WARNING "%s invoked process-killer: "
> "gfp_mask=0x%x, order=%d, oomkilladj=%d\n",
> current->comm, gfp_mask, order, current->oomkilladj);
> task_lock(current);
> @@ -519,7 +519,7 @@ static void __out_of_memory(gfp_t gfp_ma
>
> if (sysctl_oom_kill_allocating_task)
> if (!oom_kill_process(current, gfp_mask, order, 0, NULL,
> - "Out of memory (oom_kill_allocating_task)"))
> + "Failure to reclaim enough memory (oom_kill_allocating_task)"))
> return;
> retry:
> /*
> @@ -534,11 +534,11 @@ retry:
> /* Found nothing?!?! Either we hang forever, or we panic. */
> if (!p) {
> read_unlock(&tasklist_lock);
> - panic("Out of memory and no killable processes...\n");
> + panic("Failure to reclaim enough memory and no killable processes...\n");
> }
>
> if (oom_kill_process(p, gfp_mask, order, points, NULL,
> - "Out of memory"))
> + "Memory reclaim failure"))
> goto retry;
> }
>
> @@ -563,7 +563,7 @@ void pagefault_out_of_memory(void)
> goto rest_and_return;
>
> if (sysctl_panic_on_oom)
> - panic("out of memory from page fault. panic_on_oom is selected.\n");
> + panic("failure to reclaim enough memory. panic_on_oom is selected.\n");
>
> read_lock(&tasklist_lock);
> __out_of_memory(0, 0); /* unknown gfp_mask and order */
> @@ -600,7 +600,7 @@ void out_of_memory(struct zonelist *zone
> return;
>
> if (sysctl_panic_on_oom == 2)
> - panic("out of memory. Compulsory panic_on_oom is selected.\n");
> + panic("failure to reclaim enough memory. Compulsory panic_on_oom is selected.\n");
>
> /*
> * Check if there were limitations on the allocation (only relevant for
> @@ -617,7 +617,7 @@ void out_of_memory(struct zonelist *zone
>
> case CONSTRAINT_NONE:
> if (sysctl_panic_on_oom)
> - panic("out of memory. panic_on_oom is selected\n");
> + panic("failure to enough reclaim memory. panic_on_oom is selected\n");
huh?
But I think that normal users won't know what reclaiming memory is anyway,
so the patch doesn't help IMO.
> /* Fall-through */
> case CONSTRAINT_CPUSET:
> __out_of_memory(gfp_mask, order);
--
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/
next prev parent reply other threads:[~2009-05-22 19:39 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 [this message]
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
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=4A16FFA7.5010005@oracle.com \
--to=randy.dunlap@oracle.com \
--cc=a.p.ziljstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=arve@android.com \
--cc=cl@linux-foundation.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.