[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090515181951.GI4451@balbir.in.ibm.com>
Date: Fri, 15 May 2009 23:49:51 +0530
From: Balbir Singh <balbir@...ux.vnet.ibm.com>
To: Dave Hansen <dave@...ux.vnet.ibm.com>
Cc: Christoph Lameter <cl@...ux-foundation.org>,
Pavel Machek <pavel@....cz>,
David Rientjes <rientjes@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...e.de>,
Nick Piggin <npiggin@...e.de>, Mel Gorman <mel@....ul.ie>,
Peter Ziljstra <a.p.ziljstra@...llo.nl>,
San Mehat <san@...roid.com>, Arve Hj?nnev?g <arve@...roid.com>,
linux-kernel@...r.kernel.org
Subject: Re: Misleading OOM messages
* Dave Hansen <dave@...ux.vnet.ibm.com> [2009-05-15 11:15:07]:
> On Fri, 2009-05-15 at 13:57 -0400, Christoph Lameter wrote:
> > > 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?
>
> See mm/oom_kill.c::mem_cgroup_out_of_memory(). A group itself can have
> an OOM done on it. It's not a system-wide oom. We just need to ensure
> that we continue to differentiate the cgroup-specific oom message from
> the general one. Maybe also include some more cgroup info in the debug
> outbut.
>
A long pending action item is to allow user space to handle cgroup
OOM. A cgroup can OOM, if the tasks in the group is way over their limit
and reclaim fails. I'll look to see if we enhance the output.
--
Balbir
--
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