Re: [PATCH] oom: always panic on OOM when panic_on_oom is configured

From: David Rientjes
Date: Mon Jun 08 2015 - 15:58:58 EST


On Sat, 6 Jun 2015, Tetsuo Handa wrote:

> For me, !__GFP_FS allocations not calling out_of_memory() _forever_ is a
> violation of the user policy.
>

I agree that we need work in this area to prevent livelocks that rely on
the contexts of other allocators to make forward progress, but let's be
clear that panicking the system is not the appropriate response. It's
nice and convenient to say we should repurpose panic_on_oom to solve
livelocks because it triggers a fast reboot in your configuration, but we,
and certainly others, can't tolerate reboots when the kernel just gives up
and the majority of the time these situations do resolve themselves.

I think the appropriate place to be attacking this problem is in the page
allocator, which is responsible for the page allocations in the context of
the gfp flags given to it, and not the oom killer. The oom killer is just
supposed to pick a process, send it a SIGKILL, and give it a reasonable
expectation of being able to exit.

> If kswapd found nothing more to reclaim and/or kswapd cannot continue
> reclaiming due to lock dependency, can't we consider as out of memory
> because we already tried to reclaim memory which would have been done by
> __GFP_FS allocations?
>
> Why do we do "!__GFP_FS allocations do not call out_of_memory() because
> they have very limited reclaim ability"? Both GFP_NOFS and GFP_NOIO
> allocations will wake up kswapd due to !__GFP_NO_KSWAPD, doesn't it?
>

The !__GFP_FS exception is historic because the oom killer would trigger
waaay too often if it were removed simply because it doesn't have a great
chance of allowing reclaim to succeed. Instead, we rely on external
memory freeing or other parallel allocators being able to reclaim memory.
What happens when there is no external freeing, nothing else is trying to
reclaim, or nothing else is able to reclaim? Yeah, that's the big
problem. In my opinion, there's three ways of attacking it: (1)
preallocation so we are less dependent on the page allocator in these
contexts, (2) memory reserves in extraordinary circumstances to allow
forward progress (it's already tunable by min_free_kbytes), and (3)
eventual page allocation failure when neither of these succeed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/