On Thu, 1 Nov 2012, Andrew Morton wrote: > > Exiting threads, those with PF_EXITING set, can pagefault and require > > memory before they can make forward progress. This happens, for instance, > > when a process must fault task->robust_list, a userspace structure, before > > detaching its memory. > > > > These threads also aren't guaranteed to get access to memory reserves > > unless oom killed or killed from userspace. The oom killer won't grant > > memory reserves if other threads are also exiting other than current and > > stalling at the same point. This prevents needlessly killing processes > > when others are already exiting. > > > > Instead of special casing all the possible sitations between PF_EXITING > > getting set and a thread detaching its mm where it may allocate memory, > > which probably wouldn't get updated when a change is made to the exit > > path, the solution is to give all exiting threads access to memory > > reserves if they call the oom killer. This allows them to quickly > > allocate, detach its mm, and free the memory it represents. > > Seems very sensible. > > > Acked-by: Minchan Kim <minchan@xxxxxxxxxx> > > Tested-by: Luigi Semenzato <semenzato@xxxxxxxxxx> > > What did Luigi actually test? Was there some reproducible bad behavior > which this patch fixes? > Yeah, it's briefly described in the first paragraph. He had an oom condition where threads were faulting on task->robust_list and repeatedly called the oom killer but it would defer killing a thread because it saw other PF_EXITING threads. This can happen anytime we need to allocate memory after setting PF_EXITING and before detaching our mm; if there are other threads in the same state then the oom killer won't do anything unless one of them happens to be killed from userspace. So instead of only deferring for PF_EXITING and !task->robust_list, it's better to just give them access to memory reserves to prevent a potential livelock so that any other faults that may be introduced in the future in the exit path don't cause the same problem (and hopefully we don't allow too many of those!). -- 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>