Re: cgroup information proc file format

[Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>]

On 08/11/2011 05:55 PM, Daniel Lezcano wrote:
> Hi all,
>
> the cgroup cpuset and memory reduce access to a part of the resources on
> the system. Some applications use the /proc/cpuinfo and /proc/meminfo to
> allocate the resources. For instance, HPC jobs look at /proc/cpuinfo to
> fork the number of cpu found in this file either look at /proc/meminfo
> to allocate a big chunk of memory. Each process set the affinity on each
> cpu, which in case a subset of cpus is used, some affinity will fail.
>
> In the case of the container, the cgroup is used to reduce the memory or
> to assign a cpu to the container. Unfortunately, as this partitioning is
> not reflected in /proc, the different system tools (ps, top, free, ...)
> show a wrong information.
>
> I was wondering if that would make sense to create for the different
> cgroup subsystem, when it is relevant, a proc formatted file we can bind
> mount /proc.
>
> For example: /cgroup/memory.proc and /cgroup/cpuset.proc

Not only that. user/sys/nice,etc statistics also are expected to be 
different than the main system one, among other things.

One way I was thinking of doing it, was to always show per-cgroup
data in /proc files when relevant, using the cgroup of the current
process as a base.

bind mounting proc files from their cgroup is a nice alternative, 
though. But it leaves the possibility of any user of it not setting it 
up. Although it is certainly more flexible, it makes me wonder if a 
constrained process should ever know about resources it can't access...

If bind mounts are used, I'd suggest we represent them as directories,
like cpuset.proc/cpuinfo. (It is not clear for me what exactly you meant
in your proposal, sorry if it was just that). This might make things 
easier to setup an isolated /proc, since we can convention that anything
in this format is available to be bind mounted, instead of having to
convention that /cgroup/cpuset.proc means /proc/cpuinfo (May matter for 
future features)

> Any ideas ?
>
>    -- Daniel
>
>
> _______________________________________________
> Containers mailing list
> Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
> https://lists.linux-foundation.org/mailman/listinfo/containers