On Mon, 18 Jul 2016, Michal Hocko wrote: > > There's > > two fundamental ways to go about it: (1) ensure mempool_alloc() can make > > forward progress (whether that's by way of gfp flags or access to memory > > reserves, which may depend on the process context such as PF_MEMALLOC) or > > (2) rely on an implementation detail of mempools to never access memory > > reserves, although it is shown to not livelock systems on 4.7 and earlier > > kernels, and instead rely on users of the same mempool to return elements > > to the freelist in all contexts, including oom contexts. The mempool > > implementation itself shouldn't need any oom awareness, that should be a > > page allocator issue. > > OK, I agree that we have a certain layer violation here. __GFP_NOMEMALLOC at > the mempool level is kind of hack (like the whole existence of the > flag TBH). So if you believe that the OOM part should be handled at the > page allocator level then that has already been proposed > http://lkml.kernel.org/r/2d5e1f84-e886-7b98-cb11-170d7104fd13@xxxxxxxxxxxxxxxxxxx > and not welcome because it might have other side effects as _all_ > __GFP_NOMEMALLOC users would be affected. > __GFP_NOMEMALLOC is opt-in and is a workaround for PF_MEMALLOC in this context to prevent a depletion of reserves, so it seems trivial to allow mempool_alloc(__GFP_NOMEMALLOC) in contexts where it's needed and leave it to the user. -- 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>