Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763455AbXJZVC6 (ORCPT ); Fri, 26 Oct 2007 17:02:58 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753925AbXJZVCu (ORCPT ); Fri, 26 Oct 2007 17:02:50 -0400 Received: from smtp2.linux-foundation.org ([207.189.120.14]:46035 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753878AbXJZVCu (ORCPT ); Fri, 26 Oct 2007 17:02:50 -0400 Date: Fri, 26 Oct 2007 14:02:01 -0700 From: Andrew Morton To: Marcelo Tosatti Cc: linux-kernel@vger.kernel.org, drepper@redhat.com, riel@redhat.com, Martin Bligh , linux-mm@kvack.org Subject: Re: OOM notifications Message-Id: <20071026140201.ae52757c.akpm@linux-foundation.org> In-Reply-To: <20071018201531.GA5938@dmt> References: <20071018201531.GA5938@dmt> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1669 Lines: 42 On Thu, 18 Oct 2007 16:15:31 -0400 Marcelo Tosatti wrote: > Hi, > > AIX contains the SIGDANGER signal to notify applications to free up some > unused cached memory: > > http://www.ussg.iu.edu/hypermail/linux/kernel/0007.0/0901.html > > There have been a few discussions on implementing such an idea on Linux, > but nothing concrete has been achieved. > > On the kernel side Rik suggested two notification points: "about to > swap" (for desktop scenarios) and "about to OOM" (for embedded-like > scenarios). > > With that assumption in mind it would be necessary to either have two > special devices for notification, or somehow indicate both events > through the same file descriptor. > > Comments are more than welcome. Martin was talking about some mad scheme wherin you'd create a bunch of pseudo files (say, /proc/foo/0, /proc/foo/1, ..., /proc/foo/9) and each one would become "ready" when the MM scanning priority reaches 10%, 20%, ... 100%. Obviously there would need to be a lot of abstraction to unhook a permanent userspace feature from a transient kernel implementation, but the basic idea is that a process which wants to know when the VM is getting into the orange zone would select() on the file "7" and a process which wants to know when the VM is getting into the red zone would select on file "9". It get more complicated with NUMA memory nodes and cgroup memory controllers. - 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/