Re: Discussion on my OOM killer API

Re: Discussion on my OOM killer API

[Rik van Riel]

On Thu, 19 Oct 2000, Ingo Oeser wrote:

> You might remember the shortest "API" ever: The OOM killer API[1]
> I posted during the last round of hot discussion on OOM killing.
> 
> What are the reasons of not including it? Its only a few lines
> for a complete API. 
> 
> I could have made it full blown with reference counting,
> automatic releasing old OOM killers and a nice proc interface[2]
> for letting the user say which he wants. 

> I'm also willing to maintain it ;-)

Linus, how would you feel about an interface that allows
people to insomd/rmmod their own OOM handler ?

I think we should be able to do this in less than half
a kb of kernel code and it might be able to get the last
few people who complain silenced as they try to produce
their own OOM killer ;)

[and we have a maintainer ... what else do we need ? ]

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
       -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/		http://www.surriel.com/

--
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/

Re: Discussion on my OOM killer API

[Linus Torvalds]

On Thu, 19 Oct 2000, Rik van Riel wrote:
> 
> > I'm also willing to maintain it ;-)
> 
> Linus, how would you feel about an interface that allows
> people to insomd/rmmod their own OOM handler ?

I hate the idea.

I dislike that kind of approach in general. I don't like plug-in
schedulers, etc either. I think it's a cop-out, saying that we cannot do a
good enough job, and claiming that it's such a difficult problem that we
should let the user decide. And in the end it ends up just screwing
everybody, because all the modules will do the wrong thing in some
circumstances, and nobody ever bothers to test _their_ module for anything
but the case they care about.

In short, it's one of those things that sounds like a good idea, but that
results in absolute crap in the end.

		Linus

--
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/

Re: Discussion on my OOM killer API

[Rik van Riel]

On Thu, 26 Oct 2000, Linus Torvalds wrote:
> On Thu, 19 Oct 2000, Rik van Riel wrote:
> > > I'm also willing to maintain it ;-)
> > 
> > Linus, how would you feel about an interface that allows
> > people to insomd/rmmod their own OOM handler ?
> 
> I hate the idea.

*grin*

I agree with that, except for one small point...

> I dislike that kind of approach in general. I don't like plug-in
> schedulers, etc either. I think it's a cop-out, saying that we
> cannot do a good enough job, and claiming that it's such a
> difficult problem that we should let the user decide.

... the generic OOM killer we have in the system right now
should do a good job in most of the cases, but I've heard
from a number of people who would like to have the OOM killer
do something "special" for their system.

For instance, they want to have student programs killed before
staff programs, or want to be able to specify some priveledged
processes that will never be killed (or do other things that
we probably don't want to have in the generic killer).

> In short, it's one of those things that sounds like a good idea,
> but that results in absolute crap in the end.

Sure, but the idea is to keep this absolute crap out of
the kernel and local to the systems where people need
to replace the OOM killer because of special reasons ;)

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
       -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/		http://www.surriel.com/

--
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/

Re: Discussion on my OOM killer API

[Mark Hahn]

> from a number of people who would like to have the OOM killer
> do something "special" for their system.

if they are few and/or special enough, it makes a lot more sense
for them to just maintain a private patch.  actually, I've never
seen a discussion of why such needs couldn't be served by a "god" 
process that mlocks itself, runs at RT, etc.  there are some minor
details to work out (does it poll, or get some hook?)

> For instance, they want to have student programs killed before
> staff programs, or want to be able to specify some priveledged
> processes that will never be killed (or do other things that

which could all be accomplished by providing a simple priority:
even 8 bits of ordering would probably be overkill...

regards, mark hahn

--
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/

Re: Discussion on my OOM killer API

[James Sutherland]

On Thu, 26 Oct 2000, Rik van Riel wrote:

> On Thu, 26 Oct 2000, Linus Torvalds wrote:
> > On Thu, 19 Oct 2000, Rik van Riel wrote:
> > > > I'm also willing to maintain it ;-)
> > > 
> > > Linus, how would you feel about an interface that allows
> > > people to insomd/rmmod their own OOM handler ?
> > 
> > I hate the idea.
> 
> *grin*
> 
> I agree with that, except for one small point...

I agree too: if we're out of memory hard enough to trigger the in-kernel
handler, blowing away almost anything would be an improvement. Ideally,
action should be taken by userspace long before this point...

> > I dislike that kind of approach in general. I don't like plug-in
> > schedulers, etc either. I think it's a cop-out, saying that we
> > cannot do a good enough job, and claiming that it's such a
> > difficult problem that we should let the user decide.
> 
> ... the generic OOM killer we have in the system right now
> should do a good job in most of the cases, but I've heard
> from a number of people who would like to have the OOM killer
> do something "special" for their system.
> 
> For instance, they want to have student programs killed before
> staff programs, or want to be able to specify some priveledged
> processes that will never be killed (or do other things that
> we probably don't want to have in the generic killer).
> 
> > In short, it's one of those things that sounds like a good idea,
> > but that results in absolute crap in the end.
> 
> Sure, but the idea is to keep this absolute crap out of
> the kernel and local to the systems where people need
> to replace the OOM killer because of special reasons ;)

Which begs the question, where did the userspace OOM policy daemon go? It,
coupled with Rik's simple in-kernel last-ditch handler, should cover most
eventualities without the need for nasty kernel kludges.


James.

--
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/

Re: Discussion on my OOM killer API

[Linus Torvalds]

On Fri, 27 Oct 2000, James Sutherland wrote:
> 
> Which begs the question, where did the userspace OOM policy daemon go? It,
> coupled with Rik's simple in-kernel last-ditch handler, should cover most
> eventualities without the need for nasty kernel kludges.

I agree. Possibly with help to the user-space OOM thing. We should
probably implement the same SIGDANGER that some other Unixes have, and
then anybody can implement their own low-on-memory thing by having a
user-mode server that does a mlockall() and reacts to SIGDANGER by
spraying anything it wants with kill(9)'s.

		Linus

--
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/

Re: Discussion on my OOM killer API

[James Sutherland]

On Thu, 26 Oct 2000, Linus Torvalds wrote:

> 
> On Fri, 27 Oct 2000, James Sutherland wrote:
> > 
> > Which begs the question, where did the userspace OOM policy daemon go? It,
> > coupled with Rik's simple in-kernel last-ditch handler, should cover most
> > eventualities without the need for nasty kernel kludges.
> 
> I agree. Possibly with help to the user-space OOM thing. We should
> probably implement the same SIGDANGER that some other Unixes have, and
> then anybody can implement their own low-on-memory thing by having a
> user-mode server that does a mlockall() and reacts to SIGDANGER by
> spraying anything it wants with kill(9)'s.

Yes, that should keep most people happy; better still, it could try other
approaches before kill9: start shouting at the console when you're down to
the last 25Mb, disable logins at 10Mb and start SIGTERMing things at 5,
perhaps. Or maybe bring some "emergency" swapspace online and disable
non-root logins. That way, if the sysadmin responds quickly enough, they
can clear out whatever THEY think is causing a problem; if not, they'll
arrive to find a fully working machine with a couple of people complaining
about Netscape having crashed yet again, rather than an init-less
machine!


James.

--
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/

Re: Discussion on my OOM killer API

[Gábor Lénárt]

On Fri, Oct 27, 2000 at 07:46:31AM +0100, James Sutherland wrote:
> Yes, that should keep most people happy; better still, it could try other
> approaches before kill9: start shouting at the console when you're down to
> the last 25Mb, disable logins at 10Mb and start SIGTERMing things at 5,
> perhaps. Or maybe bring some "emergency" swapspace online and disable
> non-root logins. That way, if the sysadmin responds quickly enough, they
> can clear out whatever THEY think is causing a problem; if not, they'll
> arrive to find a fully working machine with a couple of people complaining
> about Netscape having crashed yet again, rather than an init-less
> machine!

Sure. Implementing user-space OOM killer is much better because you can
do everything you want to react for OOM case. In kernel it would be much
more difficult to maintain and finetune, IMHO. BTW, it almost the same.
If someone wants OOM API, SIGDANGER can be considered a "stupid API".
And yes, everything should be removed from kernel space which can be done
in user space easily (and don't open other thread on microkernels ;-)

- Gabor
--
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/

Re: Discussion on my OOM killer API

[James Sutherland]

On Fri, 27 Oct 2000, Gabor Linart wrote:

> On Fri, Oct 27, 2000 at 07:46:31AM +0100, James Sutherland wrote:
> > Yes, that should keep most people happy; better still, it could try other
> > approaches before kill9: start shouting at the console when you're down to
> > the last 25Mb, disable logins at 10Mb and start SIGTERMing things at 5,
> > perhaps. Or maybe bring some "emergency" swapspace online and disable
> > non-root logins. That way, if the sysadmin responds quickly enough, they
> > can clear out whatever THEY think is causing a problem; if not, they'll
> > arrive to find a fully working machine with a couple of people complaining
> > about Netscape having crashed yet again, rather than an init-less
> > machine!
> 
> Sure. Implementing user-space OOM killer is much better because you can
> do everything you want to react for OOM case. In kernel it would be much
> more difficult to maintain and finetune, IMHO. BTW, it almost the same.
> If someone wants OOM API, SIGDANGER can be considered a "stupid API".
> And yes, everything should be removed from kernel space which can be done
> in user space easily (and don't open other thread on microkernels ;-)

Well, I'm certainly not going to start advocating microkernelising Linux!

I don't think we should remove OOM killer code from the kernel entirely,
though: supposing the oom killer dies (is killed by a malicious attacker,
unknown bug, whatever)? We MUST kill something, so we need a decent
kernel-side failsafe.

I'll make a start on coding a killer daemon soon. I think it should be the
party sending SIGDANGER (or whatever); if things get bad enough the
kernel-side killer is triggered, I think it should just blow the processes
up hard.


James.

--
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/

Re: Discussion on my OOM killer API

[Ingo Oeser]

On Fri, Oct 27, 2000 at 12:58:44AM +0100, James Sutherland wrote:
> Which begs the question, where did the userspace OOM policy daemon go? It,
> coupled with Rik's simple in-kernel last-ditch handler, should cover most
> eventualities without the need for nasty kernel kludges.

If I do the full blown variant of my patch: 

echo "my-kewl-oom-killer" >/proc/sys/vm/oom_handler

will try to load the module with this name for a new one and
uninstall the old one.

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 ;-)

Regards

Ingo Oeser

[1] http://www.tu-chemnitz.de/~ioe/oom_kill_api.patch
[2] That's why I called it "simpliest API ever" ;-)
-- 
Feel the power of the penguin - run linux@your.pc
<esc>:x
--
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/

Re: Discussion on my OOM killer API

[James Sutherland]

On Fri, 27 Oct 2000, Ingo Oeser wrote:

> On Fri, Oct 27, 2000 at 12:58:44AM +0100, James Sutherland wrote:
> > Which begs the question, where did the userspace OOM policy daemon go? It,
> > coupled with Rik's simple in-kernel last-ditch handler, should cover most
> > eventualities without the need for nasty kernel kludges.
> 
> If I do the full blown variant of my patch: 
> 
> echo "my-kewl-oom-killer" >/proc/sys/vm/oom_handler
> 
> will try to load the module with this name for a new one and
> uninstall the old one.

EBADIDEA. The kernel's OOM killer is a last ditch "something's going to
die - who's first?" - adding extra bloat like this is BAD.

Policy should be decided user-side, and should prevent the kernel-side
killer EVER triggering.

> 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?


James.

--
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/

Re: Discussion on my OOM killer API

[jfm2]

> 
> On Fri, 27 Oct 2000, Ingo Oeser wrote:
> 
> > On Fri, Oct 27, 2000 at 12:58:44AM +0100, James Sutherland wrote:
> > > Which begs the question, where did the userspace OOM policy daemon go? It,
> > > coupled with Rik's simple in-kernel last-ditch handler, should cover most
> > > eventualities without the need for nasty kernel kludges.
> > 
> > If I do the full blown variant of my patch: 
> > 
> > echo "my-kewl-oom-killer" >/proc/sys/vm/oom_handler
> > 
> > will try to load the module with this name for a new one and
> > uninstall the old one.
> 
> EBADIDEA. The kernel's OOM killer is a last ditch "something's going to
> die - who's first?" - adding extra bloat like this is BAD.
> 
> Policy should be decided user-side, and should prevent the kernel-side
> killer EVER triggering.
> 

Only problem is that your user side process will have been pushed out
of memory by netcape and that in this kind of situations it will take
a looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong
time to be recalled from swap and it being able to kill anything.
Well before it comes back netscape will have eaten all remaining
memory so kernel will have to decide by itself.

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.

> > 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()
}

-- 
			Jean Francois Martinez


--
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/

Re: Discussion on my OOM killer API

[James Sutherland]

On Sat, 28 Oct 2000 jfm2@club-internet.fr wrote:

> > 
> > On Fri, 27 Oct 2000, Ingo Oeser wrote:
> > 
> > > On Fri, Oct 27, 2000 at 12:58:44AM +0100, James Sutherland wrote:
> > > > Which begs the question, where did the userspace OOM policy daemon go? It,
> > > > coupled with Rik's simple in-kernel last-ditch handler, should cover most
> > > > eventualities without the need for nasty kernel kludges.
> > > 
> > > If I do the full blown variant of my patch: 
> > > 
> > > echo "my-kewl-oom-killer" >/proc/sys/vm/oom_handler
> > > 
> > > will try to load the module with this name for a new one and
> > > uninstall the old one.
> > 
> > EBADIDEA. The kernel's OOM killer is a last ditch "something's going to
> > die - who's first?" - adding extra bloat like this is BAD.
> > 
> > Policy should be decided user-side, and should prevent the kernel-side
> > killer EVER triggering.
> > 
> 
> Only problem is that your user side process will have been pushed out
> of memory by netcape and that in this kind of situations it will take
> a looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong
> time to be recalled from swap and it being able to kill anything.

Ehm... nope. mlockall().

> Well before it comes back netscape will have eaten all remaining
> memory so kernel will have to decide by itself.

Ehm... nope. My process is locked in physical memory, and has realtime
priority: once my daemon decides to go into action, Netscape doesn't get
any more memory, CPU time or anything else, just a quick SIGKILL.

> 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.

> > > 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?


James.

--
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/

Re: Discussion on my OOM killer API

[jfm2]

> 
> > 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/

Re: Discussion on my OOM killer API

[James Sutherland]

On Sat, 28 Oct 2000 jfm2@club-internet.fr wrote:

> > > 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).

So you agree the OOM handler can be in userspace without unacceptable
overhead?

> > > 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.

I knew it wasn't intended as a serious comment, but the point remains: the
guesswork involved is too complex and variable to belong in the kernel.
This sort of "intelligent" handling of complex situations should only be
attempted from userspace: the kernel MUST be kept as simple as possible.
As a last resort, kill anything "suspicious" looking, until the problem
has gone. If we aren't that far gone, leave it to userspace to sort the
problem out.


James.

--
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/

Re: Discussion on my OOM killer API

[Jeremy Fitzhardinge]

[-- Attachment #1: Type: text/plain, Size: 245 bytes --]

On Fri, Oct 27, 2000 at 11:11:11PM +0100, James Sutherland wrote:
> Ehm... nope. mlockall().

Better make sure it's statically linked...  don't want every random library
locked down in their entirety just because the oom killer is using it.

	J

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: Discussion on my OOM killer API

[James Sutherland]

On Fri, 27 Oct 2000, Jeremy Fitzhardinge wrote:

> On Fri, Oct 27, 2000 at 11:11:11PM +0100, James Sutherland wrote:
> > Ehm... nope. mlockall().
> 
> Better make sure it's statically linked...  don't want every random library
> locked down in their entirety just because the oom killer is using it.

Of course. I did point that out, later in the mail you are replying to...


James.

--
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/

Re: Discussion on my OOM killer API

[G?bor L?n?rt]

On Sat, Oct 28, 2000 at 12:12:59AM +0200, jfm2@club-internet.fr wrote:
> > > echo "my-kewl-oom-killer" >/proc/sys/vm/oom_handler
> > > 
> > > will try to load the module with this name for a new one and
> > > uninstall the old one.
> > 
> > EBADIDEA. The kernel's OOM killer is a last ditch "something's going to
> > die - who's first?" - adding extra bloat like this is BAD.

Yep.

> > Policy should be decided user-side, and should prevent the kernel-side
> > killer EVER triggering.
> > 
> 
> Only problem is that your user side process will have been pushed out
> of memory by netcape and that in this kind of situations it will take
> a looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong

Nope. Use mlock().
Second it's clear that we should implement a stupid kernel side OOM killer
too in case of something goes really wrong, but that killer can be really
stupid and constant part of system. In normal cases user space OOM killer
should do the job for us ...

- Gabor
--
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/

Re: Discussion on my OOM killer API

[James Sutherland]

On Mon, 30 Oct 2000, G?bor L?n?rt wrote:

> > > Policy should be decided user-side, and should prevent the kernel-side
> > > killer EVER triggering.
> > > 
> > 
> > Only problem is that your user side process will have been pushed out
> > of memory by netcape and that in this kind of situations it will take
> > a looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong
> 
> Nope. Use mlock().
> Second it's clear that we should implement a stupid kernel side OOM killer
> too in case of something goes really wrong, but that killer can be really
> stupid and constant part of system. In normal cases user space OOM killer
> should do the job for us ...

Yes, that's my plan. AIUI, Ingo is going to do the kernel hooks I need,
I'll do the userspace policy daemon?


James.

--
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/

Re: Discussion on my OOM killer API

[G?bor L?n?rt]

On Mon, Oct 30, 2000 at 09:41:33AM +0000, James Sutherland wrote:
> On Mon, 30 Oct 2000, G?bor L?n?rt wrote:
> 
> > > > Policy should be decided user-side, and should prevent the kernel-side
> > > > killer EVER triggering.
> > > > 
> > > 
> > > Only problem is that your user side process will have been pushed out
> > > of memory by netcape and that in this kind of situations it will take
> > > a looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong
> > 
> > Nope. Use mlock().
> > Second it's clear that we should implement a stupid kernel side OOM killer
> > too in case of something goes really wrong, but that killer can be really
> > stupid and constant part of system. In normal cases user space OOM killer
> > should do the job for us ...
> 
> Yes, that's my plan. AIUI, Ingo is going to do the kernel hooks I need,
> I'll do the userspace policy daemon?

Sounds nice, but be carefull with mlock. If your userspace OOM killer
needs something special library, mlockall() lock its reversed memory
area in main memory too while probably that lib is not used by other apps !

IMHO, writing mlock()'ed application is a bad idea IN general, so you must
take care ... Probably try to use assembly for x86 ;-) or simply C programm
without any EXTRA lib ... OK, libc is not critical, since libc should fit
in memory ... almost every reachable program use it of course ...

- Gabor
--
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/

Re: Discussion on my OOM killer API

[J.A. Sutherland]

--On 30 October 2000, 10:53 +0100 "G?bor L?n?rt" <lgb@viva.uti.hu> wrote:
> On Mon, Oct 30, 2000 at 09:41:33AM +0000, James Sutherland wrote:
>> On Mon, 30 Oct 2000, G?bor L?n?rt wrote:
>> 
>> > > > Policy should be decided user-side, and should prevent the
>> > > > kernel-side killer EVER triggering.
>> > > > 
>> > > 
>> > > Only problem is that your user side process will have been pushed out
>> > > of memory by netcape and that in this kind of situations it will take
>> > > a
>> > > looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong
>> > 
>> > Nope. Use mlock().
>> > Second it's clear that we should implement a stupid kernel side OOM
>> > killer too in case of something goes really wrong, but that killer can
>> > be really stupid and constant part of system. In normal cases user
>> > space OOM killer should do the job for us ...
>> 
>> Yes, that's my plan. AIUI, Ingo is going to do the kernel hooks I need,
>> I'll do the userspace policy daemon?
> 
> Sounds nice, but be carefull with mlock. If your userspace OOM killer
> needs something special library, mlockall() lock its reversed memory
> area in main memory too while probably that lib is not used by other apps
> !
> 
> IMHO, writing mlock()'ed application is a bad idea IN general, so you must
> take care ... Probably try to use assembly for x86 ;-) or simply C
> programm without any EXTRA lib ... OK, libc is not critical, since libc
> should fit in memory ... almost every reachable program use it of course

Locking even libc into physical memory is something I'd really rather not
do.
Having said that, I'll wait and see what I can do with the daemon!


James.
--
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/

Re: Discussion on my OOM killer API

[Ingo Oeser]

On Fri, Oct 27, 2000 at 06:36:13PM +0100, James Sutherland wrote:
> > If I do the full blown variant of my patch: 
> EBADIDEA. The kernel's OOM killer is a last ditch "something's going to
> die - who's first?" - adding extra bloat like this is BAD.
 
Ok. So it's easier for me ;-)

> Policy should be decided user-side, and should prevent the kernel-side
> killer EVER triggering.
 
So your user space OOM handler would like to be notified on
memory *pressure* (not only about OOM)? You would like to shrink
image caches and the like with it? Sounds sane. 

But then we need information on _how_ much memory we need. I
could pass allocation "priority" to user space, but I doubt that
will be descriptive enough.

> 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?

If you could clarify, what events you actually like to get, I
could implement this a loadable OOM handler.

But still my patch is much more flexible, since it even allows to
panic & reboot. I would prefer that on embedded systems, which
boot _really_ fast, over blowing the system by adding mutally
watching to my important processes.

Regards

Ingo Oeser
-- 
Feel the power of the penguin - run linux@your.pc
<esc>:x
--
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/

Re: Discussion on my OOM killer API

[James Sutherland]

On Sun, 29 Oct 2000, Ingo Oeser wrote:

> On Fri, Oct 27, 2000 at 06:36:13PM +0100, James Sutherland wrote:
> > > If I do the full blown variant of my patch: 
> > EBADIDEA. The kernel's OOM killer is a last ditch "something's going to
> > die - who's first?" - adding extra bloat like this is BAD.
>  
> Ok. So it's easier for me ;-)

Also a plus point, I think :)

> > Policy should be decided user-side, and should prevent the kernel-side
> > killer EVER triggering.
>  
> So your user space OOM handler would like to be notified on
> memory *pressure* (not only about OOM)? You would like to shrink
> image caches and the like with it? Sounds sane. 

That's a bit more elaborate than my plan, but I'd like to get that at some
point (2.5?) - "Hey, X, we're getting short on RAM here. How about
ditching a few cached bitmaps?" etc.

My plan for now was simpler: my handler gets notified "only x Mb left!"
and works down a priority list of things to try at each threshold: maybe
kill netscapes if we're down to 2 Mb, send a SIGDANGER to everyone at 1
Mb, reboot if we drop below 0.5 Mb.

> But then we need information on _how_ much memory we need. I
> could pass allocation "priority" to user space, but I doubt that
> will be descriptive enough.

Memory pressure is very difficult to measure, but if the configuration is
flexible enough the daemon should be able to handle most things.

> > 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?
> 
> If you could clarify, what events you actually like to get, I
> could implement this a loadable OOM handler.

The main event I'm interested in is "free memory below <level>" (and "free
memory above <level>"; users may want things restarted once the problem
has gone). Having the same facility for short-term load average might be
nice, too, to catch fork-bombs etc. before they hurt the system too badly.

The mechanism I have in mind is something like this:

1. System boots up, init loads /sbin/resourced

2. resourced works out the nearest threshold of interest, and writes this
to /dev/resources, then performs a blocking read (i.e. sleeps until that
threshold is crossed). (Runs as root, realtime maximum priority.)

3. As a threshold is crossed, the read will return appropriate
information: which threshold was crossed, for example. This wakes
resourced, which takes appropriate action.

For a simple configuration, I'd probably just want to warn logged-in users
when we drop below, say, 5 Mb, then start killing things at 1 Mb.

> But still my patch is much more flexible, since it even allows to
> panic & reboot. I would prefer that on embedded systems, which
> boot _really_ fast, over blowing the system by adding mutally
> watching to my important processes.

I'd rather reboot cleanly from userspace if possible, avoiding the panic()
route. OK, in an embedded system you may not have big RAID arrays to fsck
etc., but I think most programmers would rather not have the system panic
unnecessarily?


James.

--
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/