From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227]) by kanga.kvack.org (Postfix) with SMTP id B59746B004D for ; Thu, 29 Oct 2009 19:51:13 -0400 (EDT) Received: from m4.gw.fujitsu.co.jp ([10.0.50.74]) by fgwmail5.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id n9TNpACW003441 for (envelope-from kamezawa.hiroyu@jp.fujitsu.com); Fri, 30 Oct 2009 08:51:11 +0900 Received: from smail (m4 [127.0.0.1]) by outgoing.m4.gw.fujitsu.co.jp (Postfix) with ESMTP id A609845DE7B for ; Fri, 30 Oct 2009 08:51:10 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (s4.gw.fujitsu.co.jp [10.0.50.94]) by m4.gw.fujitsu.co.jp (Postfix) with ESMTP id 7B00E45DE79 for ; Fri, 30 Oct 2009 08:51:10 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id 600E31DB803F for ; Fri, 30 Oct 2009 08:51:10 +0900 (JST) Received: from m107.s.css.fujitsu.com (m107.s.css.fujitsu.com [10.249.87.107]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id EAE901DB8037 for ; Fri, 30 Oct 2009 08:51:09 +0900 (JST) Date: Fri, 30 Oct 2009 08:48:36 +0900 From: KAMEZAWA Hiroyuki Subject: Re: Memory overcommit Message-Id: <20091030084836.5428e085.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: References: <4ADE3121.6090407@gmail.com> <20091026105509.f08eb6a3.kamezawa.hiroyu@jp.fujitsu.com> <4AE5CB4E.4090504@gmail.com> <20091027122213.f3d582b2.kamezawa.hiroyu@jp.fujitsu.com> <4AE78B8F.9050201@gmail.com> <4AE792B8.5020806@gmail.com> <20091028135519.805c4789.kamezawa.hiroyu@jp.fujitsu.com> <20091028150536.674abe68.kamezawa.hiroyu@jp.fujitsu.com> <20091028152015.3d383cd6.kamezawa.hiroyu@jp.fujitsu.com> <4AE97861.1070902@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org To: David Rientjes Cc: vedran.furac@gmail.com, Hugh Dickins , linux-mm@kvack.org, linux-kernel@vger.kernel.org, KOSAKI Motohiro , minchan.kim@gmail.com, Andrew Morton , Andrea Arcangeli List-ID: On Thu, 29 Oct 2009 12:53:42 -0700 (PDT) David Rientjes wrote: > > If you have OOM situation and Xorg is the first, that means it's leaking > > memory badly and the system is probably already frozen/FUBAR. Killing > > krunner in that situation wouldn't do any good. From a user perspective, > > nothing changes, system is still FUBAR and (s)he would probably reboot > > cursing linux in the process. > > > > It depends on what you're running, we need to be able to have the option > of protecting very large tasks on production servers. Imagine if "test" > here is actually a critical application that we need to protect, its > not solely mlocked anonymous memory, but still kill if it is leaking > memory beyond your approximate 2.5GB. How do you do that when using rss > as the baseline? As I wrote repeatedly, - OOM-Killer itselfs is bad thing, bad situation. - The kernel can't know the program is bad or not. just guess it. - Then, there is no "correct" OOM-Killer other than fork-bomb killer. - User has a knob as oom_adj. This is very strong. Then, there is only "reasonable" or "easy-to-understand" OOM-Kill. "Current biggest memory eater is killed" sounds reasonable, easy to understand. And if total_vm works well, overcommit_guess should catch it. Please improve overcommit_guess if you want to stay on total_vm. Thanks, -Kame -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org