Patch: oom_kill

Patch: oom_kill

[Axel Kittenberger]

A small patch to discuss, it's about killing an process in an out-of-memory 
condition. First from the code I don't see any prohibition that it kills 
init, if reaches maximum badness points, don't think thats something anybody 
anytime wants. Sure for desktop systems this very unlikely to ever occur, but 
for small embedded systems that could happen. 

Second proposal is to give processes that are direct childs from init a 
special bonus, normally that are those we don't want to get killed. They are 
either important or get respawned eitherway creating an endless oom condition 
loop when killing them.

A position to think about is to generally bonus processes from their distance 
to init. The further down in the hirachy to more unlikely it is for the 
process to be important.

Greetings, Axel


diff -ru linux-2.4.20-org/mm/oom_kill.c linux-2.4.20/mm/oom_kill.c
--- linux-2.4.20-org/mm/oom_kill.c	Fri Nov 29 00:53:15 2002
+++ linux-2.4.20/mm/oom_kill.c	Tue Feb  4 12:10:40 2003
@@ -62,6 +62,11 @@
 	if (!p->mm)
 		return 0;
 	/*
+	 * Never kill init
+	 */
+	if (p->pid == 1)
+		return 0:        
+	/*
 	 * The memory size of the process is the basis for the badness.
 	 */
 	points = p->mm->total_vm;
@@ -101,6 +106,15 @@
 	 */
 	if (cap_t(p->cap_effective) & CAP_TO_MASK(CAP_SYS_RAWIO))
 		points /= 4;
+
+	/*
+	 * Give childs from init a bonus, they usually get respawned
+	 * eitherway, killing them might not help to solve the out of memory 
+	 * condition in the long run.
+	 */
+	if (p->p_pptr != NULL && p->p_pptr->pid == 1) 
+		points /= 4;
+        
 #ifdef DEBUG
 	printk(KERN_DEBUG "OOMkill: task %d (%s) got %d points\n",
 	p->pid, p->comm, points);

Re: Patch: oom_kill

[Jesse Pollard]

On Tuesday 04 February 2003 06:32 am, Axel Kittenberger wrote:
> A small patch to discuss, it's about killing an process in an out-of-memory
> condition. First from the code I don't see any prohibition that it kills
> init, if reaches maximum badness points, don't think thats something
> anybody anytime wants. Sure for desktop systems this very unlikely to ever
> occur, but for small embedded systems that could happen.

ok.

> Second proposal is to give processes that are direct childs from init a
> special bonus, normally that are those we don't want to get killed. They
> are either important or get respawned eitherway creating an endless oom
> condition loop when killing them.

And what about processes that get reparented to init? These could be causing
the OOM. I didn't think that the p_ptr was null when reparenting happens.

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: Patch: oom_kill

[Axel Kittenberger]

> And what about processes that get reparented to init? These could be
> causing the OOM. I didn't think that the p_ptr was null when reparenting
> happens.

Okay good, should we use the "original parent" instead?

Yes, I'm not absolutly not sure if the != NULL expression is necessary, Don't 
know enough about the task structering for this. I tried without and the 
machine at least didn't crash, but just wanted to be safe.

Re: Patch: oom_kill

[Jesse Pollard]

On Tuesday 04 February 2003 08:13 am, Axel Kittenberger wrote:
> > And what about processes that get reparented to init? These could be
> > causing the OOM. I didn't think that the p_ptr was null when reparenting
> > happens.
>
> Okay good, should we use the "original parent" instead?

I'm not familiar enough with the reparenting to know. I'm not sure you can 
tell the difference.

> Yes, I'm not absolutly not sure if the != NULL expression is necessary,
> Don't know enough about the task structering for this. I tried without and
> the machine at least didn't crash, but just wanted to be safe.

I was considering that a possible test for a reparented process since the
original parent doesn't necessarily exist anymore, though it would make
more sense to have that point to init, than point to anything else.

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.