lkml.org 
[lkml]   [2015]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] oom: always panic on OOM when panic_on_oom is configured
From
Date
Michal Hocko wrote:
> > > Let's move check_panic_on_oom up before the current task is
> > > checked so that the knob value is . Do the same for the memcg in
> > > mem_cgroup_out_of_memory.
> > >
> > > Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > > Signed-off-by: Michal Hocko <mhocko@suse.cz>
> >
> > Nack, this is not the appropriate response to exit path livelocks. By
> > doing this, you are going to start unnecessarily panicking machines that
> > have panic_on_oom set when it would not have triggered before. If there
> > is no reclaimable memory and a process that has already been signaled to
> > die to is in the process of exiting has to allocate memory, it is
> > perfectly acceptable to give them access to memory reserves so they can
> > allocate and exit. Under normal circumstances, that allows the process to
> > naturally exit. With your patch, it will cause the machine to panic.
>
> Isn't that what the administrator of the system wants? The system
> is _clearly_ out of memory at this point. A coincidental exiting task
> doesn't change a lot in that regard. Moreover it increases a risk of
> unnecessarily unresponsive system which is what panic_on_oom tries to
> prevent from. So from my POV this is a clear violation of the user
> policy.

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

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?

Are objects reclaimed by kswapd and objects reclaimed by __GFP_FS allocations
differ? If yes, we could introduce a proxy kernel thread which does __GFP_FS
allocations on behalf of !__GFP_FS allocators, and notify !__GFP_FS allocators
of completion. If no, why not to call out_of_memory() when kswapd found nothing
more to reclaim and/or kswapd cannot continue reclaiming due to lock dependency?

At least, I expect some warning like check_hung_task() in kernel/hung_task.c
is emitted when memory allocation livelock/deadlock is suspected. That will
help detecting unresponsive systems.


\
 
 \ /
  Last update: 2015-06-06 09:01    [W:0.312 / U:0.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site