On Mon, 18 Jul 2016, Michal Hocko wrote: > David Rientjes was objecting that such an approach wouldn't help if the > oom victim was blocked on a lock held by process doing mempool_alloc. This > is very similar to other oom deadlock situations and we have oom_reaper > to deal with them so it is reasonable to rely on the same mechanism > rather inventing a different one which has negative side effects. > Right, this causes oom livelock as described in the aforementioned thread: the oom victim is waiting on a mutex that is held by a thread doing mempool_alloc(). The oom reaper is not guaranteed to free any memory, so nothing on the system can allocate memory from the page allocator. I think the better solution here is to allow mempool_alloc() users to set __GFP_NOMEMALLOC if they are in a context which allows them to deplete memory reserves. -- 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>