Re: [PATCH] oom killer (Core)

[Andrea Arcangeli]

On Sat, Dec 04, 2004 at 10:02:03PM +0100, Thomas Gleixner wrote:
> On Sat, 2004-12-04 at 19:33 +0100, Thomas Gleixner wrote:
> >
> > I added some debug output and it calls __alloc_pages a couple of times.
> > All those calls get out from the first goto got_pg as expected.
> > 
> > I will try to add some more debug later
> > 
> 
> Your assumption that reverting the 
> 
> -       might_sleep_if(wait);
> +       if (wait)
> +               cond_resched();
> 
> change does solve the problem is correct. Looking at the diffs its the
> only change which can have any influence at this point.
> 
> Mats. I don't understand why this did not work for you. The change has
> to be reverted to the original line "might_sleep_if(wait)" !

Ok, so some piece of code is buggy: somebody is using GFP_KERNEL instead
of GFP_ATOMIC.  Reverting my change will only hide the real bug so I
wouldn't recommend it (except for testing purposes).

Would be very nice to find the real bug.

> It then works so far except that it kills the wrong process (sshd), but
> I did expect that from the previous experience. 
> 
> There is no multi kill or other strange things happening. I tested it
> with hackbench and the real application _after_ adding my "whom to kill
> patch" on top.
> 
> Looks much better now. 

So you mean there's a separate issue with the task selection right? I
didn't touch the task selection at all.

> Can you agree to add the selection patch, which takes the multi child
> forking process into account ? I don't explain again why it makes
> sense :)

I didn't recall that part of your patch, but it seems very orthogonal. I
didn't want to change the process selection at the same time. If I will
touch the task selection I'll probably rewrite it from scratch to choose
tasks only in function of the allocation rate, sure not with anything
similar to the current algorithm which is close to a DoS with big
database servers if some other smaller app hits a memleak and allocates
in a loop.
-
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/