On Tue, Jun 26, 2012 at 04:19:26PM +0200, Peter Zijlstra wrote: > On Tue, 2012-06-26 at 16:11 +0200, Johannes Weiner wrote: > > > > Should the warning be emitted for any memcg, not just the parent? If > > somebody takes notice of the changed semantics, it's better to print > > the warning on the first try to disable hierarchies instead of holding > > back until they walk up the tree and try to change it in the root. > > Still forbid disabling at lower levels, just be more eager to inform > > the people trying it. > > *blink* You mean you can mix-and-match use_hierarchy over the hierarchy? > Can I have some of those drugs? It must be strong and powerful stuff > that. You can create root/a/b/c/d/e and enable hierarchy in b, which ends up treating (a) and (b+children) like siblings even though they nest in the cgroup fs. Yes, drugs. But you can't disable the hierarchy if you have a hierarchy-enabled parent, which we try to make the new default. So in case somebody has an existing setup that happened to nest group directories without hierarchy and so never used memory.use_hierarchy before, they'll probably try to disable it where it bothers them, below the root group, which will get them -EBUSY, nothing else. I'm just asking to warn in that case as well and suggest they get their directory structure in order, to save them some time wondering wtf changed. -- 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>