Difference between revisions of "Mainline Kernel Virtualization"
From Linux-VServer
(Added Paul Menage's new patchset) |
(Added containers (v7)) |
||
Line 27: | Line 27: | ||
: - support for a subsystem to keep a container alive via refcounts (e.g. the BeanCounters numfiles counter has a reference to the beancounter object from each file charged to that beancounter, so needs to be able to keep the beancounter alive until the file is destroyed) | : - support for a subsystem to keep a container alive via refcounts (e.g. the BeanCounters numfiles counter has a reference to the beancounter object from each file charged to that beancounter, so needs to be able to keep the beancounter alive until the file is destroyed) | ||
+ | |||
+ | * 12.02.2007 [http://lkml.org/lkml/2007/2/12/88 containers (V7): Generic Process Containers] by '''Paul Menage''' (from '''Google''') | ||
+ | |||
+ | : This is an update to my multi-hierarchy multi-subsystem generic process containers patch. Changes since V6 (22nd December) include: | ||
+ | |||
+ | : - updated to 2.6.20 | ||
+ | |||
+ | : - added more details about multiple hierarchy support in the documentation | ||
+ | |||
+ | : - reduced the per-task memory overhead to one pointer (previously it was one pointer for each hierarchy). Now each task has a pointer to a container_group, which holds the pointers to the containers (one per active hierarchy) that the task is attached to and the associated per-subsystem state (one per active subsystem). This container group is shared (with reference counts) between all tasks that have the same set of container mappings. | ||
+ | |||
+ | : - added API support for binding/unbinding subsystems to/from active hierarchies, by remounting with -oremount,<new-subsys-list>. Currently this fails with EBUSY if the hierarchy has a child containers; full implementation support is left to a later patch. | ||
+ | |||
+ | : - added a bind() subsystem callback to indicate when a subsystem is moved between hierarchies | ||
+ | |||
+ | : - added container_clone(subsys, task), which creates a child container for the hierarchy that the specified subsystem is bound to, and moves the given task into that container. An example use of this would be in sys_unshare, which could, if the namespace container subsystem is active, create a child container when the new namespace is created. | ||
+ | |||
+ | : - temporarily removed the "release agent" support. It's only currently used by CPUsets, and intrudes somewhat on the per-container reference counting. If necessary it can be re-added, either as a generic subsystem feature or a CPUset-specific feature, via a kernel thread that periodically polls containers that have been designated as notify_on_release to see if they are releasable |
Revision as of 13:57, 12 February 2007
Actively Developed Patches
- 19.09.2006 Containers(V2) by Rohit Seth (from Google) based on CPUsets
- Over the limit memory handler is called when number of pages (anon + pagecache) exceed the limit. Currently, this memory handler scans the mappings and tasks belonging to container (file and anonymous) and tries to deactivate pages. If the number of page cache pages is also high then it also invalidate mappings.
- 20.10.2006 Generic Containers Patchset by Paul Menage (from Google) based on CPUset subsystem
- This patchset extracts the process grouping code from cpusets into a generic container system, and makes the cpusets code a client of the container system.
- It also provides a very simple additional container subsystem to do per-container CPU usage accounting; this is primarily to demonstrate use of the container subsystem API, but is useful in its own right.
- 17.11.2006 Multi-hierarchy Process Containers by Paul Menage (from Google)
- This is an update to my generic containers patch. The major change is support for multiple hierarchies of containers (up to a limit specified at build time).
- Note that this hasn't yet undergone intensive testing following the multi-hierarchy introduction, but I wanted to get the basic idea out for comments.
- 13.11.2006 Generic Process Containers (+ResGroups/BeanCounters) by Paul Menage (from Google)
- This is an update to my multi-hierarchy generic containers patch (against 2.6.19-rc6). Changes include:
- - an example patch implementing the BeanCounters core and numfiles counters over generic containers. The addition of the BeanCounters code unifies the three main process grouping abstractions (Cpusets, ResGroups and BeanCounters).
- - a patch splitting Cpusets into two independently groupable subsystems, Cpusets and Memsets.
- - support for a subsystem to keep a container alive via refcounts (e.g. the BeanCounters numfiles counter has a reference to the beancounter object from each file charged to that beancounter, so needs to be able to keep the beancounter alive until the file is destroyed)
- 12.02.2007 containers (V7): Generic Process Containers by Paul Menage (from Google)
- This is an update to my multi-hierarchy multi-subsystem generic process containers patch. Changes since V6 (22nd December) include:
- - updated to 2.6.20
- - added more details about multiple hierarchy support in the documentation
- - reduced the per-task memory overhead to one pointer (previously it was one pointer for each hierarchy). Now each task has a pointer to a container_group, which holds the pointers to the containers (one per active hierarchy) that the task is attached to and the associated per-subsystem state (one per active subsystem). This container group is shared (with reference counts) between all tasks that have the same set of container mappings.
- - added API support for binding/unbinding subsystems to/from active hierarchies, by remounting with -oremount,<new-subsys-list>. Currently this fails with EBUSY if the hierarchy has a child containers; full implementation support is left to a later patch.
- - added a bind() subsystem callback to indicate when a subsystem is moved between hierarchies
- - added container_clone(subsys, task), which creates a child container for the hierarchy that the specified subsystem is bound to, and moves the given task into that container. An example use of this would be in sys_unshare, which could, if the namespace container subsystem is active, create a child container when the new namespace is created.
- - temporarily removed the "release agent" support. It's only currently used by CPUsets, and intrudes somewhat on the per-container reference counting. If necessary it can be re-added, either as a generic subsystem feature or a CPUset-specific feature, via a kernel thread that periodically polls containers that have been designated as notify_on_release to see if they are releasable