Re: [RFC][PATCH 1/4] Generic container system abstracted from cpusets code

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

On 9/28/06, Paul Jackson <pj@sgi.com> wrote:
> Be sure to spell out, if you haven't already, that there is just a
> single container hierarchy, with each task attached to a single
> container in that hierarchy, and each subsystem (e.g. cpusets)
> adding its own special files to the common container hierarchy
> directories.
>
> It is not the case that each subsystem using containers gets to
> concoct its own hierarchy, independent of any other subsystem.

Well, it wouldn't be too hard to have the container code manage
multiple container hierarchies in parallel if people wanted the
ability to do this. You'd just replace the

   struct container *container;

field in task_struct with

   struct container *containers[MAX_CONTAINER_HIERARCHIES]

and have each instance of the container filesystem manage a different
hierarchy. Perhaps to configure this from userspace you could do
something like

mount -t container xxx -octype=cpuset /dev/cpuset
mount -t container yyy -octype=resgroup,ctype=cpuacct /mnt/rescontainer

i.e. mount one container hierarchy on /dev/cpuset with just the cpuset
container type, and mount an independent hierarchy on
/mnt/rescontainer with the resgroup and cpuacct container types
attached to it. You'd probably want to enforce a rule that each
container type could only be attached to a single hierarchy at a time.

Anyone have any thoughts on the usefulness/insanity of such an idea?
The most useful part of it may be the ability to e.g. create a
container hierarchy that explicitly doesn't cause e.g. multiple
cpusets to be created, if you want to avoid the overhead that kicks in
when there are multiple cpusets in use. That could be approximated
without the overhead of multiple container hierarchy support by having
a control file(s) in the top container dir that lets you configure
which container subsystems are actually in use. So e.g. if you turned
cpusets off before creating any subcontainers, all containers would
actually share the same cpuset instance, and we could avoid any of the
overheads associated with having multiple cpusets.

This would be somewhere in between the existing state of a single
hierarchy with multiple fixed container types, and the full-blown
multiple hierarchies with configurably-attachable container types that
I outlined above.

> If someone configures in one or more of the subsystems, such as
> cpusets, that requires CONTAINERS, then we need to enable containers.
> Otherwise we don't need to enable CONTAINERS.  I don't see what
> user input we need here specific to CONTAINERS.

Fair enough - so have the various container types do "select
CONTAINERS" rather than "depends on CONTAINERS"?

> > + *  Copyright (C) 2003 BULL SA.
> > + *  Copyright (C) 2004-2006 Silicon Graphics, Inc.
>
> Perhaps you want to add a Google or Menage copyright here?
>
> > + *  2003-10-22 Updates by Stephen Hemminger.
> > + *  2004 May-July Rework by Paul Jackson.
>
> Perhaps time for another log line here, such as:
>   + *  2006 Generalized to containers by Paul Menage.

I already had something like that at the top - I've now made it
clearer that these copyright statements came from the cpuset.c code
from which this code was abstracted.

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/