From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754555Ab0BOC4j (ORCPT ); Sun, 14 Feb 2010 21:56:39 -0500 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]:49475 "EHLO fgwmail6.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754182Ab0BOC4i (ORCPT ); Sun, 14 Feb 2010 21:56:38 -0500 X-SecurityPolicyCheck-FJ: OK by FujitsuOutboundMailChecker v1.3.1 From: KOSAKI Motohiro To: David Rientjes Subject: Re: [patch 1/7 -mm] oom: filter tasks not sharing the same cpuset Cc: kosaki.motohiro@jp.fujitsu.com, Andrew Morton , Rik van Riel , KAMEZAWA Hiroyuki , Nick Piggin , Andrea Arcangeli , Balbir Singh , Lubos Lunak , linux-kernel@vger.kernel.org, linux-mm@kvack.org In-Reply-To: References: Message-Id: <20100215115154.727B.A69D9226@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.07 [ja] Date: Mon, 15 Feb 2010 11:56:34 +0900 (JST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Tasks that do not share the same set of allowed nodes with the task that > triggered the oom should not be considered as candidates for oom kill. > > Tasks in other cpusets with a disjoint set of mems would be unfairly > penalized otherwise because of oom conditions elsewhere; an extreme > example could unfairly kill all other applications on the system if a > single task in a user's cpuset sets itself to OOM_DISABLE and then uses > more memory than allowed. > > Killing tasks outside of current's cpuset rarely would free memory for > current anyway. > > Signed-off-by: David Rientjes This patch does right thing and looks promissing. but unfortunately I have to NAK this patch temporary. This patch is nearly just revert of the commit 7887a3da75. We have to dig archaeology mail log and find why this reverting don't cause the old pain again. However, I personally think we end up to merge this. It is the reason I've used "temporary". > --- > mm/oom_kill.c | 12 +++--------- > 1 files changed, 3 insertions(+), 9 deletions(-) > > diff --git a/mm/oom_kill.c b/mm/oom_kill.c > --- a/mm/oom_kill.c > +++ b/mm/oom_kill.c > @@ -35,7 +35,7 @@ static DEFINE_SPINLOCK(zone_scan_lock); > /* #define DEBUG */ > > /* > - * Is all threads of the target process nodes overlap ours? > + * Do all threads of the target process overlap our allowed nodes? > */ > static int has_intersects_mems_allowed(struct task_struct *tsk) > { > @@ -167,14 +167,6 @@ unsigned long badness(struct task_struct *p, unsigned long uptime) > points /= 4; > > /* > - * If p's nodes don't overlap ours, it may still help to kill p > - * because p may have allocated or otherwise mapped memory on > - * this node before. However it will be less likely. > - */ > - if (!has_intersects_mems_allowed(p)) > - points /= 8; > - > - /* > * Adjust the score by oom_adj. > */ > if (oom_adj) { > @@ -266,6 +258,8 @@ static struct task_struct *select_bad_process(unsigned long *ppoints, > continue; > if (mem && !task_in_mem_cgroup(p, mem)) > continue; > + if (!has_intersects_mems_allowed(p)) > + continue; > > /* > * This task already has access to memory reserves and is > > -- > 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