From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262580AbVAJWqb (ORCPT ); Mon, 10 Jan 2005 17:46:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262573AbVAJWmc (ORCPT ); Mon, 10 Jan 2005 17:42:32 -0500 Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:23978 "EHLO www.linux.org.uk") by vger.kernel.org with ESMTP id S262550AbVAJWkQ (ORCPT ); Mon, 10 Jan 2005 17:40:16 -0500 Date: Mon, 10 Jan 2005 17:39:53 -0200 From: Marcelo Tosatti To: Mauricio Lin Cc: linux-kernel@vger.kernel.org Subject: Re: User space out of memory approach Message-ID: <20050110193953.GA18601@logos.cnet> References: <3f250c71050110134337c08ef0@mail.gmail.com> <20050110192012.GA18531@logos.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050110192012.GA18531@logos.cnet> User-Agent: Mutt/1.5.5.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 10, 2005 at 05:20:13PM -0200, Marcelo Tosatti wrote: > On Mon, Jan 10, 2005 at 05:43:23PM -0400, Mauricio Lin wrote: > > Hi all, > > > > We have done a comparison between the kernel version and user space > > version and apparently the behavior is similar. You can also get this > > patch and module to test it and compare with kernel OOM Killer. Here > > goes a patch and a module that moves the kernel space OOM Killer > > algorithm to user space. Let us know about your ideas. > > No comments on the code itself - It is interesting to have certain pids "not selectable" by > the OOM killer. Patches which have similar funcionality have been floating around. > > The userspace OOM killer is dangerous though. You have to guarantee that allocations > will NOT happen until the OOM killer is executed and the killed process is dead and > has its pages freed - allocations under OOM can cause deadlocks. > > "OOM-killer-in-userspace" is unreliable, not sure if its worth the effort making > it reliable (mlock it, flagged as PF_MEMALLOC, etc). Actually its only unreliable if its called from OOM time. The case here is you have a daemon which periodically writes to /proc/oom ?