lkml.org 
[lkml]   [2015]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: can't oom-kill zap the victim's memory?
From
Date
On 10/07/2015 12:43 PM, Tetsuo Handa wrote:
> Vlastimil Babka wrote:
>> On 5.10.2015 16:44, Michal Hocko wrote:
>>> So I can see basically only few ways out of this deadlock situation.
>>> Either we face the reality and allow small allocations (withtout
>>> __GFP_NOFAIL) to fail after all attempts to reclaim memory have failed
>>> (so after even OOM killer hasn't made any progress).
>>
>> Note that small allocations already *can* fail if they are done in the context
>> of a task selected as OOM victim (i.e. TIF_MEMDIE). And yeah I've seen a case
>> when they failed in a code that "handled" the allocation failure with a
>> BUG_ON(!page).
>>
> Did You hit a race described below?

I don't know, I don't even have direct evidence of TIF_MEMDIE being set,
but OOMs were happening all over the place, and I haven't found another
reason why the allocation would not be too-small-to-fail otherwise.

> http://lkml.kernel.org/r/201508272249.HDH81838.FtQOLMFFOVSJOH@I-love.SAKURA.ne.jp
>
> Where was the BUG_ON(!page) ? Maybe it is a candidate for adding __GFP_NOFAIL.

Yes, I suggested so:
http://marc.info/?l=linux-kernel&m=144181523115244&w=2



\
 
 \ /
  Last update: 2015-10-08 12:01    [W:1.825 / U:0.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site