Re: User space out of memory approach

[Mauricio Lin]

On Mon, 10 Jan 2005 17:39:53 -0200, Marcelo Tosatti
<marcelo.tosatti@xxxxxxxxxxxx> wrote:
> 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 ?
Yes, let me explain the idea.
When the memory consumption reaches a percentage of usage, as 98% or
something like that, we call this as red zone. So when red zone is
reached, the ranking algorithm is started to select which processes
could be killed whe out of memory happens. If the memory comsumption
is less than this percentage (not in red zone), the ranking algorithm
is not executed. So we have a loop the check the memory comsumption
all the time and if the red zone is reached, the ranking algorithm is
started before the system get the out of memory state.

BR,

Mauricio Lin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/