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@xxxxxxxxxxxxxxxxxxx> > > > Signed-off-by: Michal Hocko <mhocko@xxxxxxx> > > > > 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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>