Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754399AbZKDDWe (ORCPT ); Tue, 3 Nov 2009 22:22:34 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754078AbZKDDWd (ORCPT ); Tue, 3 Nov 2009 22:22:33 -0500 Received: from fgwmail5.fujitsu.co.jp ([192.51.44.35]:47206 "EHLO fgwmail5.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753899AbZKDDWc (ORCPT ); Tue, 3 Nov 2009 22:22:32 -0500 X-SecurityPolicyCheck-FJ: OK by FujitsuOutboundMailChecker v1.3.1 Date: Wed, 4 Nov 2009 12:19:52 +0900 From: KAMEZAWA Hiroyuki 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 Subject: Re: Memory overcommit Message-Id: <20091104121952.07ea695a.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: References: <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> Organization: FUJITSU Co. LTD. X-Mailer: Sylpheed 2.5.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2351 Lines: 52 On Tue, 3 Nov 2009 19:10:34 -0800 (PST) David Rientjes wrote: > 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'll not go too quickly, so, let's discuss and rewrite patches more, later. I'll parepare new version in the next week. For this week, I'll post swap accounting and improve fork-bomb detector. > 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. > Yes, I think allocation itself (> order=0) should fail more before we finally invoke OOM. It tends to be soft-landing rather than oom-killer. Thanks, -Kame -- 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/