lkml.org 
[lkml]   [2015]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: can't oom-kill zap the victim's memory?
On Tue, 29 Sep 2015, Tetsuo Handa wrote:

> > The point I've tried to made is that oom unmapper running in a detached
> > context (e.g. kernel thread) vs. directly in the oom context doesn't
> > make any difference wrt. lock because the holders of the lock would loop
> > inside the allocator anyway because we do not fail small allocations.
>
> We tried to allow small allocations to fail. It resulted in unstable system
> with obscure bugs.
>

These are helpful to identify regardless of the outcome of this
discussion. I'm not sure where the best place to report them would be,
or whether its even feasible to dig through looking for possibilities, but
I think it would be interesting to see which callers are relying on
internal page allocator implementation to work properly since it may
uncover bugs that would occur later if it were changed.


\
 
 \ /
  Last update: 2015-09-29 00:41    [W:0.308 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site