Re: [ckrm-tech] [RFC] Resource Management - Infrastructure choices

["Paul Menage" <menage@google.com>]

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