Thomas Gleixner wrote:
> On Sun, 2004-11-21 at 14:57 +0100, Thomas Gleixner wrote:
> 
>>On Sun, 2004-11-21 at 13:17 +0100, Martin MOKREJŠ wrote:
>>
>>>Why can't the algorithm first find the asking for memory now.
>>>When found, kernel should kill first it's children, wait some time,
>>>then kill this process if still exists (it might exit itself when children
>>>get closed).
>>>You have said it's safer to kill that to send ENOMEM as happens
>>>in 2.4, but I still don't undertand why kernel first doesn't send
>>>ENOMEM, and only if that doesn't help it can start after those 5 seconds
>>>OOM killer, and try to kill the very same application.
>>>I don't get the idea why to kill immediately.
>>
>>I see your concern. There are some more changes neccecary to make this
>>reliably work. I'm not sure if it can be done without really big
>>changes. I will look a bit deeper into this.
> 
> 
> One big problem when killing the requesting process or just sending
> ENOMEM to the requesting process is, that exactly this process might be
> a ssh login, when you try to log into to machine after some application
> went crazy and ate up most of the memory. The result is that you
> _cannot_ log into the machine, because the login is either killed or
> cannot start because it receives ENOMEM.

I believe the application is _first_ who will get ENOMEM. It must be
terrible luck that it would ask exactly for the size of remaining free
memory. Most probably, it will ask for less or more. "Less" in not
a problem in this case, so consider it asks for more. Then, OOM killer
might well expect the application asking for memory is most probably
exactly the application which caused the trouble.

> 
> Putting hard coded decisions like "prefer sshd, xyz,...", " don't kill
> a, b, c" are out of discussion.

I'd go for it at least nowadays.

>  
> The ideas which were proposed to have a possibility to set a "don't kill
> me" or "yes, I'm a candidate" flag are likely to be a future way to go.
> But at the moment we have no way to make this work in current userlands.

Do you think login or sshd will ever use flag "yes, I'm a candidate"?
I think exactly same bahaviour we get right now with those hard coded decisions
you mention above. Otherwise the hard coded decision is programmed into
every sshd, init instance anyway. I think it's not necessary to put
login and shells on thsi ban list, user will re-login again. ;)

> 
> I refined the decision, so it does not longer kill the parent, if there
> were forked child processes available to kill. So it now should keep
> your bash alive.

Yes, it doesn't kill parent bash. I don't understand the _doubled_ output
in syslog, but maybe you do. Is that related to hyperthreading? ;)
Tested on 2.6.10-rc2-mm2.