On Wed, 18 Apr 2007, Yasunori Goto wrote:
> If panic_on_oom is 1, only panic if mempolicy/cpuset is not used.
> And if panic_on_oom is 2, panic on all case.
> This might be desirable.
Sounds good. Add some documentation mentioned that this may panic your
system if there is still plenty of memory
On Tue, 17 Apr 2007, Larry Woodman wrote:
> On Tue, 2007-04-17 at 14:39 -0700, Christoph Lameter wrote:
>
> >
> > It recreates the old problem that we OOM while we still have memory
> > in other parts of the system.
>
> How, by the time we get here we have already decided we are going to
> OOM
> On Tue, 17 Apr 2007, Larry Woodman wrote:
>
> > out_of_memory() does not panic when sysctl_panic_on_oom is set
> > if constrained_alloc() does not return CONSTRAINT_NONE. Instead,
> > out_of_memory() kills the current process whenever constrained_alloc()
> > returns either CONSTRAINT_MEMORY_POL
On Tue, 2007-04-17 at 14:39 -0700, Christoph Lameter wrote:
>
> It recreates the old problem that we OOM while we still have memory
> in other parts of the system.
How, by the time we get here we have already decided we are going to
OOMkill or panic. This change just obeys sysctl_panic_on_oom
On Tue, 17 Apr 2007, Larry Woodman wrote:
> out_of_memory() does not panic when sysctl_panic_on_oom is set
> if constrained_alloc() does not return CONSTRAINT_NONE. Instead,
> out_of_memory() kills the current process whenever constrained_alloc()
> returns either CONSTRAINT_MEMORY_POLICY or CONST
out_of_memory() does not panic when sysctl_panic_on_oom is set
if constrained_alloc() does not return CONSTRAINT_NONE. Instead,
out_of_memory() kills the current process whenever constrained_alloc()
returns either CONSTRAINT_MEMORY_POLICY or CONSTRAINT_CPUSET.
This patch fixes this problem:
Sign
6 matches
Mail list logo
