David Rientjes wrote: > I think both of your illustrations show why it is not helpful to kill > additional processes after a time period has elapsed and a victim has > failed to exit. In both of your scenarios, it would require that KT1 be > killed to allow forward progress and we know that's not possible. My illustrations show why it is helpful to kill additional processes after a time period has elapsed and a victim has failed to exit. We don't need to kill KT1 if we combine memory unmapping approach and timeout based OOM killing approach. Simply choosing more OOM victims (processes which do not share other OOM victim's mm) based on timeout itself does not guarantee that other OOM victims can exit. But if timeout based OOM killing is used together with memory unmapping approach, the possibility that OOM victims can exit significantly increases because the only case where memory unmapping approach stucks will be when mm->mmap_sem was held for writing (which should unlikely occur). If we choose only 1 OOM victim, the possibility of hitting this memory unmapping livelock is (say) 1%. But if we choose multiple OOM victims, the possibility becomes (almost) 0%. And if we still hit this livelock even after choosing many OOM victims, it is time to call panic(). (Well, do we need to change __alloc_pages_slowpath() that OOM victims do not enter direct reclaim paths in order to avoid being blocked by unkillable fs locks?) > > Perhaps this is an argument that we need to provide access to memory > reserves for threads even for !__GFP_WAIT and !__GFP_FS in such scenarios, > but I would wait to make that extension until we see it in practice. I think that GFP_ATOMIC allocations already access memory reserves via ALLOC_HIGH priority. > > Killing all mm->mmap_sem threads certainly isn't meant to solve all oom > killer livelocks, as you show. > Good. I'm not denying memory unmapping approach. I'm just pointing out that use of memory unmapping approach alone still leaves room for hang up. -- 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>