On Thu, 18 Jun 2015, Michal Hocko wrote: > That is to be discussed. Most allocations already express their interest > in memory reserves by __GFP_HIGH directly or by GFP_ATOMIC indirectly. > So maybe we do not need any additional flag here. There are not that > many ~__GFP_WAIT and most of them seem to require it _only_ because the > context doesn't allow for sleeping (e.g. to prevent from deadlocks). > We're talking about a patch that is being backported to stable. Regardless of what improvements can be made to specify that an allocation shouldn't be able to access reserves (and what belongs solely in the page allocator proper) independent of __GFP_NO_KSWAPD, that can be cleaned up at a later time. I don't anticipate that cleanup to be backported to stable, and my primary concern here is the ability for this allocations to now access, and possibly 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>