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

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

On 11/7/06, Paul Jackson <pj@sgi.com> wrote:
> How about /proc/<pid>/containers being a directory, with each
> controller having one regular file entry (so long as we haven't done
> the multiple controller instances in my item (5)) containing the path,
> relative to some container file system mount point (which container
> mount is up to user space code to track) of the container that contains
> that task?

Hmm. Seems a bit fancier than necessary, but maybe reasonable. I'll
probably start with a single file listing all the different container
associations and we can turn it into a directory later as a finishing
touch.

> Or how about each controller type, such as cpusets, having its own
> /proc/<pid>/<controller-type> file, with no generic file
> /proc</pid>/container at all.  Just extend the current model
> seen in /proc/<pid>/cpuset ?

Is it possible to dynamically extend the /proc/<pid>/ directory? If
not, then every container subsystem would involve a patch in
fs/proc/base.c, which seems a bit nasty.

> However this fits in nicely with my expectation that we will have
> only limited need, if any, in the short term, to run systems with
> both cpusets and resource groups at the same time.

We're currently planning on using cpusets for the memory node
isolation properties, but we have a whole bunch of other resource
controllers that we'd like to be able to hang off the same
infrastructure, so I don't think the need is that limited.

> And while we're here, how about each controller naming itself with a
> well known string compiled into its kernel code, and a file such
> as /proc/containers listing what controllers are known to it?  Not

The naming is already in my patch. You can tell from the top-level
directory which containers are registered, since each one has an
xxx_enabled file to control whether it's in use; there's not a
separate /proc/containers file yet.

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/