| Name |
Last commit
|
Last update |
|---|---|---|
| config | ||
| doc | ||
| hooks | ||
| src | ||
| templates | ||
| .gitignore | ||
| .travis.yml | ||
| AUTHORS | ||
| CONTRIBUTING | ||
| COPYING | ||
| INSTALL | ||
| MAINTAINERS | ||
| Makefile.am | ||
| NEWS | ||
| README | ||
| TODO | ||
| autogen.sh | ||
| configure.ac | ||
| lxc.pc.in | ||
| lxc.spec.in |
There are only a few times when we need to be connected to the cgroup manager: * when starting a container, from cgm_init until we've set cgroup limits * when changing a cgroup setting (while running) * when cleaning up (when shutting down) * around the cgroup entering at attach So only connect/disconnect the cgmanager socket on-demand as needed. This should have a few benefits. 1. Reduce the # open fds when many containers are running 2. if cgmanager is stopped and restarted, the container doesn't have to deal with the disconnection. This is currently RFC. There are a few issues outstanding: 1. the cgm_set and cgm_get may need to be made thread-safe. 2. a non-daemonized start which fails while cgm is connected, will not disconnected. Signed-off-by:Serge Hallyn <serge.hallyn@ubuntu.com> Acked-by:
Stéphane Graber <stgraber@ubuntu.com>
| Name |
Last commit
|
Last update |
|---|---|---|
| config | Loading commit data... | |
| doc | Loading commit data... | |
| hooks | Loading commit data... | |
| src | Loading commit data... | |
| templates | Loading commit data... | |
| .gitignore | Loading commit data... | |
| .travis.yml | Loading commit data... | |
| AUTHORS | Loading commit data... | |
| CONTRIBUTING | Loading commit data... | |
| COPYING | Loading commit data... | |
| INSTALL | Loading commit data... | |
| MAINTAINERS | Loading commit data... | |
| Makefile.am | Loading commit data... | |
| NEWS | Loading commit data... | |
| README | Loading commit data... | |
| TODO | Loading commit data... | |
| autogen.sh | Loading commit data... | |
| configure.ac | Loading commit data... | |
| lxc.pc.in | Loading commit data... | |
| lxc.spec.in | Loading commit data... |