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.