On Sun, 16.06.13 15:15, Tejun Heo (tj@xxxxxxxxxx) wrote: > We want composability regardless of migration, but as for migration > itself, an alternative could be having an atomic "move everything in > cgroup A to cgroup B" interface, so that the admin (whether human or > base system software) can set up a new cgroup and then move the member > tasks atomically. I am not sure this would cut it for containers. For containers we'll usually have a fully populated cgroup subtree, and if we want to migrate that somewhere else, then we'd something that works recursively and allows us to not tell the container at all about the move (i.e. the namespace of cgroupfs the container sees should ideall stay entirely unaltered by the move). Lennart -- Lennart Poettering - Red Hat, Inc. -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
