On Fri, Aug 28, 2015 at 04:53:01PM -0400, Tejun Heo wrote: > On Fri, Aug 28, 2015 at 11:45:54PM +0300, Vladimir Davydov wrote: > > Actually, memory.high by itself *is* the protection against GFP_NOWAIT > > allocations, similarly to zone watermarks. W/o it we would have no other > > choice but fail a GFP_NOWAIT allocation on hitting memory.max. One > > should just set it so that > > > > memory.max - memory.high > [max sum size of !__GFP_WAIT allocations > > that can normally occur in a row] > > While this would be true in many cases, I don't think this is the > intention of the two knobs and the space between high and max can be > filled up by anything which can't be reclaimed - e.g. too many dirty / > writeback pages on a slow device or memlocked pages. If it were > really the buffer for GFP_NOWAIT, there's no reason to even make it a > separate knob and we *may* change how over-high reclaim behaves in the > future, so let's please not dig ourselves into something too specific. Yep, come to think of it, you're right. One might want to use the memory.high knob as the protection, because currently it is the only way to protect kmemcg against GFP_NOWAIT failures, but it looks more like abusing it :-/ We should probably think about introducing some kind of watermarks that would trigger memcg reclaim, asynchronous or direct, on exceeding them. Thanks, Vladimir -- 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>