From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by kanga.kvack.org (Postfix) with ESMTP id B8FF76B0044 for ; Wed, 28 Oct 2009 02:17:55 -0400 (EDT) Received: from spaceape10.eur.corp.google.com (spaceape10.eur.corp.google.com [172.28.16.144]) by smtp-out.google.com with ESMTP id n9S6Hl91007585 for ; Wed, 28 Oct 2009 06:17:47 GMT Received: from pwj8 (pwj8.prod.google.com [10.241.219.72]) by spaceape10.eur.corp.google.com with ESMTP id n9S6HiE6015020 for ; Tue, 27 Oct 2009 23:17:44 -0700 Received: by pwj8 with SMTP id 8so643364pwj.23 for ; Tue, 27 Oct 2009 23:17:43 -0700 (PDT) Date: Tue, 27 Oct 2009 23:17:41 -0700 (PDT) From: David Rientjes Subject: Re: Memory overcommit In-Reply-To: <20091028150536.674abe68.kamezawa.hiroyu@jp.fujitsu.com> Message-ID: References: <20091013120840.a844052d.kamezawa.hiroyu@jp.fujitsu.com> <20091014135119.e1baa07f.kamezawa.hiroyu@jp.fujitsu.com> <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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org To: KAMEZAWA Hiroyuki 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 Wed, 28 Oct 2009, KAMEZAWA Hiroyuki wrote: > All kernel engineers know "than expected or not" can be never known to the kernel. > So, oom_adj workaround is used now. (by some special users.) > OOM Killer itself is also a workaround, too. > "No kill" is the best thing but we know there are tend to be memory-leaker on bad > systems and all systems in this world are not perfect. > Right, and historically that has been addressed by considering total_vm and adjusting it with oom_adj so that we can identify memory leaking tasks through user-defined criteria. > Yes, some more trustable values other than vmsize/rss/time are appriciated. > I wonder recent memory consumption speed can be an another key value. > Sounds very logical. > Anyway, current bahavior of "killing X" is a bad thing. > We need some fixes. > You can easily protect X with OOM_DISABLE, as you know. I don't think we need any X-specific heuristics added to the kernel, it looks like the special cases have already polluted badness() enough. -- 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