On Tue 03-04-18 20:32:39, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Thu 29-03-18 14:30:03, Andrew Morton wrote: > > [...] > > > Dumb question: if a thread has been oom-killed and then tries to > > > allocate memory, should the page allocator just fail the allocation > > > attempt? I suppose there are all sorts of reasons why not :( > > > > We give those tasks access to memory reserves to move on (see > > oom_reserves_allowed) and fail allocation if reserves do not help > > > > if (tsk_is_oom_victim(current) && > > (alloc_flags == ALLOC_OOM || > > (gfp_mask & __GFP_NOMEMALLOC))) > > goto nopage; > > So we... > > > > > In which case, yes, setting a new > > > PF_MEMALLOC_MAY_FAIL_IF_I_WAS_OOMKILLED around such code might be a > > > tidy enough solution. It would be a bit sad to add another test in the > > > hot path (should_fail_alloc_page()?), but geeze we do a lot of junk > > > already. > > > > ... do not need this. > > Excuse me? But that check is after > > /* Reclaim has failed us, start killing things */ > page = __alloc_pages_may_oom(gfp_mask, order, ac, &did_some_progress); > if (page) > goto got_pg; > > which means that tsk_is_oom_victim(current) && alloc_flags == ALLOC_OOM threads > can still trigger the OOM killer as soon as the OOM reaper sets MMF_OOM_SKIP. Races are possible and I do not see them as critical _right now_. If that turnes out to be not the case we can think of a more robust way. The thing is that we have "bail out for OOM victims already". -- Michal Hocko SUSE Labs
