On Thu 02-06-16 20:31:57, Tetsuo Handa wrote: > Michal Hocko wrote: > > OK, but the memory is allocated on behalf of the parent already, right? > > What does "the memory is allocated on behalf of the parent already" mean? It means that vforked task cannot allocate a new memory directly. Sure it can get a copy of what parent already has allocated during execve but that is under control of the parent. If the parent is OOM_SCORE_ADJ_MIN then it should better be careful how it spawns new tasks. > The memory used for argv[]/envp[] may not yet be visible from mm_struct when > the OOM killer is invoked. > > > And the patch doesn't prevent parent from being selected and the vfroked > > child being killed along the way as sharing the mm with it. So what > > exactly this patch changes for this test case? What am I missing? > > If the parent is OOM_SCORE_ADJ_MIN and vfork()ed child doing execve() > with large argv[]/envp[] is not OOM_SCORE_ADJ_MIN, we should not hesitate > to OOM-kill vfork()ed child even if the parent is not OOM-killable. > > vfork() > set_oom_adj() > exec() Well the whole point of this patch is to not select such a task because it makes only very limitted sense. It cannot really free much memory - well except when parent is doing something realy stupid which I am not really sure we should care about. -- Michal Hocko SUSE Labs -- 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>