![]() | |||||||||||||
Messages in this thread |
On 11/7/06, Paul Menage <menage@google.com> wrote: > > Perhaps the interface to binding multiple controllers to a single container > > hierarchy is via multiple mount commands, each of type 'container', with > > different options specifying which controller(s) to bind. Then the > > command 'mount -t cpuset cpuset /dev/cpuset' gets remapped to the command > > 'mount -t container -o controller=cpuset /dev/cpuset'. > > Yes, that's the aproach that I'm thinking of currently. It should > require pretty reasonably robotic changes to the existing code. One drawback to this that I can see is the following: - suppose you mount a containerfs with controllers cpuset and cpu, and create some nodes, and then unmount it, what happens? do the resource nodes stick around still? - suppose you then try to mount a containers with controllers cpuset and diskio, but the resource nodes are still around, what happens then? Is there any way to prevent unmounting (at the dentry level) a busy filesystem? If we enforced a completely separate hierarchy for each resource controller (i.e. one resource controller per mount), then it wouldn't be too hard to hang the node structure off the controller itself, and there would never be a problem with mounting two controllers with existing inconsistent hierarchies on the same mount. But that would rule out being able to hook several resource controllers together in the same container node. One alternative to this would be to have a fixed number of container hierarchies; at mount time you'd mount hierarchy N, and optionally bind a set of resource controllers to it, or else use the existing set. Then the hierarchy can be hung off the appropriate entry in the hierarchy array even when the fs isn't mounted. Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-11-07 23:25 [from the cache] ©2003-2008 | |||||||||||||