From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227]) by kanga.kvack.org (Postfix) with ESMTP id 6C0586B01DD for ; Tue, 1 Jun 2010 14:36:24 -0400 (EDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id o51IaIfG025535 for ; Tue, 1 Jun 2010 11:36:20 -0700 Received: from pxi5 (pxi5.prod.google.com [10.243.27.5]) by hpaq11.eem.corp.google.com with ESMTP id o51IaGs4008932 for ; Tue, 1 Jun 2010 11:36:17 -0700 Received: by pxi5 with SMTP id 5so1895446pxi.9 for ; Tue, 01 Jun 2010 11:36:16 -0700 (PDT) Date: Tue, 1 Jun 2010 11:36:05 -0700 (PDT) From: David Rientjes Subject: Re: [RFC] oom-kill: give the dying task a higher priority In-Reply-To: Message-ID: References: <20100528152842.GH11364@uudg.org> <20100528154549.GC12035@barrios-desktop> <20100528164826.GJ11364@uudg.org> <20100531092133.73705339.kamezawa.hiroyu@jp.fujitsu.com> <20100531140443.b36a4f02.kamezawa.hiroyu@jp.fujitsu.com> <20100531145415.5e53f837.kamezawa.hiroyu@jp.fujitsu.com> <20100531155102.9a122772.kamezawa.hiroyu@jp.fujitsu.com> <20100531135227.GC19784@uudg.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org To: Minchan Kim Cc: "Luis Claudio R. Goncalves" , Peter Zijlstra , KAMEZAWA Hiroyuki , KOSAKI Motohiro , balbir@linux.vnet.ibm.com, Oleg Nesterov , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Thomas Gleixner , Mel Gorman , williams@redhat.com List-ID: On Tue, 1 Jun 2010, Minchan Kim wrote: > Secondly, as Kame pointed out, we have to raise whole thread's > priority to kill victim process for reclaiming pages. But I think it > has deadlock problem. Agreed, this has the potential to actually increase the amount of time for an oom killed task to fully exit: the exit path takes mm->mmap_sem on exit and if that is held by another thread waiting for the oom killed task to exit (i.e. reclaim has failed and the oom killer becomes a no-op because it sees an already killed task) then there's a livelock. That's always been a problem, but is compounded with increasing the priority of a task not holding mm->mmap_sem if the thread holding the writelock actually isn't looking for memory but simply doesn't get a chance to release because it fails to run. -- 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