From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757874Ab0CaGcr (ORCPT ); Wed, 31 Mar 2010 02:32:47 -0400 Received: from smtp-out.google.com ([74.125.121.35]:17655 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757341Ab0CaGcq (ORCPT ); Wed, 31 Mar 2010 02:32:46 -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=YQWgy026pWms2xfsXtOc5uUjq5a4XBLGXB1Nf9Oz771GMI5OXB4RD4wy8QDqpmpGj 9WjawT5BQZ0JeaFtVTCGA== Date: Tue, 30 Mar 2010 23:32:35 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Balbir Singh cc: KAMEZAWA Hiroyuki , anfei , Oleg Nesterov , Andrew Morton , KOSAKI Motohiro , nishimura@mxp.nes.nec.co.jp, Mel Gorman , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] oom killer: break from infinite loop In-Reply-To: <20100331063007.GN3308@balbir.in.ibm.com> Message-ID: References: <20100328145528.GA14622@desktop> <20100328162821.GA16765@redhat.com> <20100329140633.GA26464@desktop> <20100330142923.GA10099@desktop> <20100331095714.9137caab.kamezawa.hiroyu@jp.fujitsu.com> <20100331151356.673c16c0.kamezawa.hiroyu@jp.fujitsu.com> <20100331063007.GN3308@balbir.in.ibm.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 On Wed, 31 Mar 2010, Balbir Singh wrote: > > To me, this patch is acceptable and seems reasnoable. > > > > But I didn't joined to memcg development when this check was added > > and don't know why kill current.. > > > > The reason for adding current was that we did not want to loop > forever, since it stops forward progress - no error/no forward > progress. It made sense to oom kill the current process, so that the > cgroup admin could look at what went wrong. > oom_kill_process() will fail on current since it wasn't selected as an eligible task to kill in select_bad_process() and we know it to be a member of the memcg, so there's no point in trying to kill it.