[jira] [Comment Edited] (MESOS-843) Improve linux/cgroups.[hc]pp code

["Chi Zhang (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MESOS-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13832073#comment-13832073 ] 

Chi Zhang edited comment on MESOS-843 at 11/26/13 1:10 AM:
-----------------------------------------------------------

Looking at linux/cgroups.hpp, interfaces defined here belong to one of
the following
three categories:

1) system-wide cgroups state detection/manipulation:
enabled, hierarchies, hierarchy, busy, subsystems, mount, umount, mounted,
cleanup, stat

2) basic cgroup utility code for a given cgroup hierarchy:
create, remove, exists, tasks, assign, get, kill, read, write, listen, destroy

3) subsystem-specific cgroup utility code:
memory: functions in 'cgroups::memory' namespace
freezer: freeze, thaw (there isn't a freezer namespace now)

Proposed plan:

Iteration 1:

Make it such that higher level code no longer needs to worry about system-wide
cgroup state:

A cgroup isolator requests a cgroup subsystem (cpuacct, mem, etc) setup at a
given hierarchy (e.g., flags.cgroups_hierarchy) and returned a path to the
hierarchy with the requested subsystem, ready to go.

It is lower level code's responsibility to reconcile with other system
applications and libraries that use cgroup, such as systemd, lxc.

The hierarchy returned is the 'handle' to this subsystem and higher level code
uses it with 2) and 3). Nothing changed here.

(TBD: additionally, the setup code could create the root Mesos cgroup for all
hierarchies as well.)

Make linux/cgroups pseudo-OO:

The setup code handles subsystem-specific checking code pushed down from the
higher level code (e.g., check certain control files exist for cfs, etc)

Put subsystem specific code in its own namespace (e.g., create a freezer
namespace for freeze and thaw). Split cgroups::destroy code so that
sigkill-based killing is in 2) and freezer-based killing is in the freezer
namespace that belongs to 3).

Iteration 2 (Optional):

Make linux/cgroups fully OO:

Put 2) into a base class and 3) into different subclasses of 2) and kill
subsystem-specific namespaces.

Instead of using the hierarchy path as the 'handle', higher lever code requests
a cgroup subsystem object, a *singleton* instantiation of a class in
3). 'hierarchy' is now encapsulated as a property of the object. Interacting
with a cgroup subsystem becomes a matter of using functions defined in classes
in 3).

(TBD: each subsystem could be a libprocess.)

Pseudo-code:

class cgroup {
public:
create, remove, exists, tasks, assign, get, kill, read, write, listen, destroy;

protected:
cgroup(hierarchy, subystem, cgroups_root);
}

class mem : cgroup {
public:
static mem *instance(hierarchy, subystem, cgroups_root)
{ return (object == null ? (object = mem(hierarchy, subystem, cgroups_root)) : object); }
...
Try<Bytes> limit_in_bytes(...)
Try<Nothing> limit_in_bytes(...)
...
private:
static mem *object;
mem(hierarchy, subystem, cgroups_root) : cgroup(hierarchy, subystem, cgroups_root)
{ // mem specific checking }
}

class freezer : cgroup {
...
@override
destroy(...)
...
}


was (Author: chzhcn):
Looking at linux/cgroups.hpp, interfaces defined here belong to one of
the following
three categories:

1) system-wide cgroups state detection/manipulation:
enabled, hierarchies, hierarchy, busy, subsystems, mount, umount, mounted,
cleanup, stat

2) basic cgroup utility code for a given cgroup hierarchy:
create, remove, exists, tasks, assign, get, kill, read, write, listen, destroy

3) subsystem-specific cgroup utility code:
memory: functions in 'cgroups::memory' namespace
freezer: freeze, thaw (there isn't a freezer namespace now)

Proposed plan:

Iteration 1:

Make it such that higher level code no longer needs to worry about system-wide
cgroup state:

A cgroup isolator requests a cgroup subsystem (cpuacct, mem, etc) setup at a
given hierarchy (e.g., flags.cgroups_hierarchy) and returned a path to the
hierarchy with the requested subsystem, ready to go.

It is lower level code's responsibility to reconcile with other system
applications and libraries that use cgroup, such as systemd, lxc.

The hierarchy returned is the 'handle' to this subsystem and higher level code
uses it with 2) and 3). Nothing changed here.

(TBD: additionally, the setup code could create the root Mesos cgroup for all
hierarchies as well.)

Make linux/cgroups pseudo-OO:

The setup code handles subsystem-specific checking code pushed down from the
higher level code (e.g., check certain control files exist for cfs, etc)

Put subsystem specific code in its own namespace (e.g., create a freezer
namespace for freeze and thaw). Split cgroups::destroy code so that
sigkill-based killing is in 2) and freezer-based killing is in the freezer
namespace that belongs to 3).

Iteration 2 (Optional):

Make linux/cgroups fully OO:

Put 2) into a base class and 3) into different subclasses of 2) and kill
subsystem-specific namespaces.

Instead of using the hierarchy path as the 'handle', higher lever code requests
a cgroup subsystem object, a *singleton* instantiation of a class in
3). 'hierarchy' is now encapsulated as a property of the object. Interacting
with a cgroup subsystem becomes a matter of using functions defined in classes
in 3).

(TBD: each subsystem could be a libprocess.)

Pseudo-code:

class cgroup {
public:
create, remove, exists, tasks, assign, get, kill, read, write, listen, destroy;

protected:
cgroup(hierarchy, subystem, cgroups_root);
}

class mem : cgroup {
public:
static mem *instance(hierarchy, subystem, cgroups_root)
{ return (object == null ? (object = mem(hierarchy, subystem, cgroups_root)) : object); }
...
Try<Bytes> limit_in_bytes(...)
Try<Nothing> limit_in_bytes(...)
...
private:
mem *object;
mem(hierarchy, subystem, cgroups_root) : cgroup(hierarchy, subystem, cgroups_root)
{ // mem specific checking }
}

class freezer : cgroup {
...
@override
destroy(...)
...
}

> Improve linux/cgroups.[hc]pp code
> ---------------------------------
>
>                 Key: MESOS-843
>                 URL: https://issues.apache.org/jira/browse/MESOS-843
>             Project: Mesos
>          Issue Type: Bug
>            Reporter: Chi Zhang
>




--
This message was sent by Atlassian JIRA
(v6.1#6144)