cgroup: status-quo and userland efforts

[Vrijendra (वृजेन्द्र) Gokhale]

On Fri, Jun 28, 2013 at 11:53 AM, Tim Hockin <thockin at hockin.org> wrote:

> On Fri, Jun 28, 2013 at 8:05 AM, Michal Hocko <mhocko at suse.cz> wrote:
> > On Thu 27-06-13 22:01:38, Tejun Heo wrote:
>
> >> Oh, that in itself is not bad.  I mean, if you're root, it's pretty
> >> easy to play with and that part is fine.  But combined with the
> >> hierarchical nature of cgroup and file permissions, it encourages
> >> people to "deligate" subdirectories to less previledged domains,
> >
> > OK, this really depends on what you expose to non-root users. I have
> > seen use cases where admin prepares top-level which is root-only but
> > it allows creating sub-groups which are under _full_ control of the
> > subdomain. This worked nicely for memcg for example because hard limit,
> > oom handling and other knobs are hierarchical so the subdomain cannot
> > overwrite what admin has said.
>
> bingo
>
>
Note that we also use cpu and io hierarchies as user accessible hierarchies.

This makes delegation possible to google workloads for subset (sub-cgroups)
creation and monitoring.


> > And the systemd, with its history of eating projects and not caring much
> > about their previous users who are not willing to jump in to the systemd
> > car, doesn't sound like a good place where to place the new interface to
> > me.
>
> +1
>
> If systemd is the only upstream implementation of this single-agent
> idea, we will have to invent our own, and continue to diverge rather
> than converge.  I think that, if we are going to pursue this model of
> a single-agent, we should make a kick-ass implementation that is
> flexible and scalable, and full-featured enough to not require
> divergence at the lowest layer of the stack.  Then build systemd on
> top of that. Let systemd offer more features and policies and
> "semantic" APIs.
>
> We will build our own semantic APIs that are, necessarily, different
> from systemd.  But we can all use the same low-level mechanism.
>
> Tim
> _______________________________________________
> Containers mailing list
> Containers at lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
>