Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757442AbZJ1GRq (ORCPT ); Wed, 28 Oct 2009 02:17:46 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757400AbZJ1GRp (ORCPT ); Wed, 28 Oct 2009 02:17:45 -0400 Received: from smtp-out.google.com ([216.239.45.13]:43487 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757391AbZJ1GRo (ORCPT ); Wed, 28 Oct 2009 02:17:44 -0400 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:user-agent:mime-version:content-type:x-system-of-record; b=aa3QuVj4DAt8a/C+OJ1+epWE0kJTdjpVILeqxC616vE5k565YzZ08H7yMOoBc9y2l 5RN6njKR2gUwHRUjK++7A== Date: Tue, 27 Oct 2009 23:17:41 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com 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 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> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1273 Lines: 31 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/