Hello, Michal. On Mon, Jun 17, 2013 at 03:51:22PM +0200, Michal Hocko wrote: > > Some configurations which are legitimate under the current parent > > might be invalid when put under a different parent. > > yes, for example all configurations where old parent is more restrictive > than the new one. For example. hardlimit in memcg or even more I'm not following the hardlimit part. Shouldn't a given hardlimit value have the same meaning regardless of where the node is located? Its application will surely be different but its meaning would be the same, no? > oom_control, swappiness or use_hierarchy which are expected to be > consistent down the hierarchy. use_hierarchy is going away. Can you please explain how oom_control and swappiness behave? > The biggest problem I can see is how the core cgroup code know when it is > OK to migrate. There might be some ongoing operations that depend on the > current tree structure. For example the hierarchical reclaim or oom > etc.. Internally, I think it should be implemented as task migrating to another cgroup - IOW, to controllers, it'll appear the same as the userland echoing the pid to cgroup.procs file on the new cgroup. That's the only sane way to implement it as controllers need to do everything which it does for the normal task migration case anyway. Matching the impedance would be the responsibility of cgroup core. > I do not think that soft reclaim which I was talking about at LSF would > change anything here as it would be pretty much the same as the hard > limit. But that is not so important. I think it's very important to have trivially stackable configurations. Maybe we can make more complex semantics work too but it's gonna be confusing like hell when combined with the level of automation we're hoping to achieve. Thanks. -- tejun _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
