Re: Discussion on my OOM killer API

[jfm2@club-internet.fr]

> 
> > Only solution is to allow the OOM never to be swapped but you also
> > need all libraries to remain in memory or have the kernel check OOM is
> > statically linked.  However this user space OOM will then have a
> > sigificantly memory larger footprint than a kernel one and don't
> > forget it cannot be swapped.
> 
> Not necessarily "significantly larger"; it can be small and simple without
> using any libraries.
> 

This I agree: a selfcontained source (ie no use of library functions
because these have to be general so marge) can produce a small binary
if you link it adequately (ie not with the standard C initilization
code).


> > > > The original idea was an simple "I install a module and lock it
> > > > into memory" approach[1] for kernel hackers, which is _really_
> > > > easy to to and flexibility for nothing[2].
> > > > 
> > > > If the Rik and Linus prefer the user-accessable variant via
> > > > /proc, I'll happily implement this.
> > > > 
> > > > I just intended to solve a "religious" discussion via code
> > > > instead of words ;-)
> > > 
> > > I was planning to implement a user-side OOM killer myself - perhaps we
> > > could split the work, you do kernel-side, I'll do the userspace bits?
> > > 
> > 
> > Hhere is an heuristic who tends to work well ;-)
> > 
> > if (short_on_memory == TRUE )  {
> >      kill_all_copies_of_netscape()
> > }
> 
> Yes, that's a good start. Now we've done that, but we're still OOM, what
> do you kill next?
> 

I thought you would notice it was a joke.  Since 99% of OOMs are
produced by netscape best kill netscape first and ask questions later.

-- 
			Jean Francois Martinez

Project Independence: Linux for the Masses
http://www.independence.seul.org

--
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.eu.org/Linux-MM/