Re: [PATCH 1/5] mm: Add __GFP_NO_OOM_KILL flag

Rafael J. Wysocki
2009-05-05T23:20:34Z

On Wednesday 06 May 2009, Andrew Morton wrote:
> On Wed, 6 May 2009 00:19:35 +0200
> "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>
> > > > + && !processes_are_frozen()) {
> > > > if (!try_set_zone_oom(zonelist, gfp_mask)) {
> > > > schedule_timeout_uninterruptible(1);
> > > > goto restart;
> > >
> > > Cool, that looks like the semantics of __GFP_NO_OOM_KILL without requiring
> > > a new gfp flag. Thanks.
> >
> > Well, you're welcome.
> >
> > BTW, I think that Andrew was actually right when he asked if I checked whether
> > the existing __GFP_NORETRY would work as-is for __GFP_FS set and
> > __GFP_NORETRY unset. Namely, in that case we never reach the code before
> > nopage: that checks __GFP_NORETRY, do we?
> >
> > So I think we shouldn't modify the 'else if' condition above and check for
> > !processes_are_frozen() at the beginning of the block below.
>
> Confused.
>
> I'm suspecting that hibernation can allocate its pages with
> __GFP_FS|__GFP_WAIT|__GFP_NORETRY|__GFP_NOWARN, and the page allocator
> will dtrt: no oom-killings.
>
> In which case, processes_are_frozen() is not needed at all?

__GFP_NORETRY alone causes it to fail relatively quickly, but I'll try with
the combination.

Anyway, even if the hibernation code itself doesn't trigger the OOM killer,
but anyone else allocates memory in parallel or after we've preallocated the
image memory, that may still trigger it. So it seems processes_are_frozen()
may still be useful?