lkml.org 
[lkml]   [2004]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] oom killer (Core)
From
Date
On Sun, 2004-12-05 at 01:27 +0100, Andrea Arcangeli wrote:
> 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:

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

Hmm, most of the allocations in early init have the GFP_WAIT bit set.
When I block the call to cond_resched() up to cpu_idle() in rest_init()
everything works. Enabling the call to cond_resched() at any place
before brings the problem back.

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

I know.

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

Yes, the modification are not interfering with your patch. They just add
the accounting of child processes to the selection.

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

That makes sense, but it does not catch processes forking a lot of
childs, because the allocation rate is not accounted to the parent.

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

The comment above badness() is the best part of it, especially the
"least surprise part" :)

* 5) we try to kill the process the user expects us to kill, this
* algorithm has been meticulously tuned to meet the principle
* of least surprise ... (be careful when you change it)

tglx


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.095 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site