Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754310AbZKDDKi (ORCPT ); Tue, 3 Nov 2009 22:10:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752237AbZKDDKi (ORCPT ); Tue, 3 Nov 2009 22:10:38 -0500 Received: from smtp-out.google.com ([216.239.45.13]:34431 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752142AbZKDDKh (ORCPT ); Tue, 3 Nov 2009 22:10:37 -0500 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=P/5sRFtiE2lKPJMO7cpg4gGJdAqmmQi6N91wiBza+gXtmfzO380HjCgy1WL9W4L7+ 8aMse14jnMQf6RC7qDrbw== Date: Tue, 3 Nov 2009 19:10:34 -0800 (PST) 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: <20091104111703.b46ae72b.kamezawa.hiroyu@jp.fujitsu.com> Message-ID: References: <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> <20091030084836.5428e085.kamezawa.hiroyu@jp.fujitsu.com> <20091030183638.1125c987.kamezawa.hiroyu@jp.fujitsu.com> <20091104095021.5532e913.kamezawa.hiroyu@jp.fujitsu.com> <20091104111703.b46ae72b.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: 2081 Lines: 46 On Wed, 4 Nov 2009, KAMEZAWA Hiroyuki wrote: > My point and your point are differnt. > > 1. All my concern is "baseline for heuristics" > 2. All your concern is "baseline for knob, as oom_adj" > > ok ? For selecting victim by the kernel, dynamic value is much more useful. > Current behavior of "Random kill" and "Kill multiple processes" are too bad. > Considering oom-killer is for what, I think "1" is more important. > > But I know what you want, so, I offers new knob which is not affected by RSS > as I wrote in previous mail. > > Off-topic: > As memcg is growing better, using OOM-Killer for resource control should be > ended, I think. Maybe Fake-NUMA+cpuset is working well for google system, > but plz consider to use memcg. > I understand what you're trying to do, and I agree with it for most desktop systems. However, I think that admins should have a very strong influence in what tasks the oom killer kills. It doesn't really matter if it's via oom_adj or not, and its debatable whether an adjustment on a static heuristic score is in our best interest in the first place. But we must have an alternative so that our control over oom killing isn't lost. I'd also like to open another topic for discussion if you're proposing such sweeping changes: at what point do we allow ~__GFP_NOFAIL allocations to fail even if order < PAGE_ALLOC_COSTLY_ORDER and defer killing anything? We both agreed that it's not always in the best interest to kill a task so that an allocation can succeed, so we need to define some criteria to simply fail the allocation instead. > Old processes are important, younger are not. But as I wrote, I'll drop > most of patch "6". So, plz forget about this part. > > I'm interested in fork-bomb killer rather than crazy badness calculation, now. > Ok, great. Thanks. -- 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/