Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753778AbZA0UnT (ORCPT ); Tue, 27 Jan 2009 15:43:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751562AbZA0UnF (ORCPT ); Tue, 27 Jan 2009 15:43:05 -0500 Received: from smtp-out.google.com ([216.239.33.17]:52323 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751519AbZA0UnC (ORCPT ); Tue, 27 Jan 2009 15:43:02 -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-gmailtapped-by:x-gmailtapped; b=MM7G10OCxzCuYkmvpP8PxDRCO8uwTLObY4gMpm7PlvjEKQQljFNZxFTeT6dqWyn1Z CsIbTwkTthIdULTCIR4Kw== Date: Tue, 27 Jan 2009 12:41:03 -0800 (PST) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Evgeniy Polyakov cc: KOSAKI Motohiro , Alan Cox , balbir@linux.vnet.ibm.com, Nikanth Karthikesan , containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org, Torvalds , Arve Hj?nnev?g , Andrew Morton , Chris Snook , Paul Menage Subject: Re: [RFC] [PATCH] Cgroup based OOM killer controller In-Reply-To: <20090127134559.GB18119@ioremap.net> Message-ID: References: <20090127093105.GB2646@ioremap.net> <20090127193058.D48B.KOSAKI.MOTOHIRO@jp.fujitsu.com> <20090127134559.GB18119@ioremap.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-GMailtapped-By: 172.25.146.78 X-GMailtapped: rientjes Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1048 Lines: 21 On Tue, 27 Jan 2009, Evgeniy Polyakov wrote: > Having some special application which will monitor /dev/mem_notify and > kill processes based on its own hueristics is a good idea, but when it > fails to do its work (or does not exist) system has to have ability to > make a progress and invoke a main oom-killer. > Agreed, very similiar to the cgroup oom notifier patch that invokes the oom killer if there are no attached tasks waiting to handle the situation. In this case, it would be a configurable delay to allow userspace to act in response to oom conditions before invoking the kernel oom killer. So instead of thinking of this as a userspace replacement for the oom killer, it simply preempts it if userspace can provide more memory, including the possibility of killing tasks itself. -- 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/