Hello, On Fri, Aug 28, 2015 at 11:32:31PM +0300, Vladimir Davydov wrote: > What kind of workload should it be then? `find` will constantly invoke > d_alloc, which issues a GFP_KERNEL allocation and therefore is allowed > to perform reclaim... > > OK, I tried to reproduce the issue on the latest mainline kernel and ... > succeeded - memory.current did occasionally jump up to ~55M although > memory.high was set to 32M. Hmm, strange... Started to investigate. > Printed stack traces and found that we don't invoke memcg reclaim on > normal GFP_KERNEL allocations! How is that? The thing is there was a > commit that made SLUB (not VFS or any other kmem user, but core SLUB) > try to allocate high order slab pages w/o __GFP_WAIT for performance > reasons. That broke kmemcg case. Here it goes: Ah, cool, so it was a bug from slub. Punting to return path still has some niceties but if we can't consistently get rid of stack consumption it's not that attractive. Let's revisit it later together with hard limit reclaim. Thanks. -- tejun -- 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>