mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH 0/6] Generic Process Containers
@ 2006-10-20 18:38 menage
  2006-10-20 18:38 ` [PATCH 1/6] Generic container system abstracted from cpusets code menage
                   ` (5 more replies)
  0 siblings, 6 replies; 13+ messages in thread
From: menage @ 2006-10-20 18:38 UTC (permalink / raw)
  To: akpm, pj, sekharan
  Cc: linux-kernel, ckrm-tech, jlan, mbligh, rohitseth, winget, Simon.Derr

--

This is an update to my generic containers patch, with the following changes:

- ported to 2.6.19-rc2
- CONFIG_CPUSETS_LEGACY_API option maintains the existing cpusets userspace API
- support for fork/exit callbacks

Patch 6 contains a port of the interesting bits of ResGroups to run
over generic containers, along with the example ResGroups numtasks
patch. It's not intended to be actually applied with this patch set,
but is an example of how other in-kernel systems might use generic
containers.

(This time built with multiple compilers and architectures)

-------------------------------------

There have recently been various proposals floating around for
resource management/accounting subsystems in the kernel, including
Res Groups, User BeanCounters and others.  These all need the basic
abstraction of being able to group together multiple processes in an
aggregate, in order to track/limit the resources permitted to those
processes, and all implement this grouping in different ways.

Already existing in the kernel is the cpuset subsystem; this has a
process grouping mechanism that is mature, tested, and well documented
(particularly with regards to synchronization rules).

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.

The change is implemented in five stages:

1) extract the process grouping code from cpusets into a standalone system

2) remove the process grouping code from cpusets and hook into the
 container system

3) convert the container system to present a generic API, and make
 cpusets a client of that API

4) add a simple CPU accounting container subsystem as an example

5) add support for fork/exit callbacks iff some subsystem is interested in them

The intention is that the various resource management efforts can also
become container clients, with the result that:

- the userspace APIs are (somewhat) normalised

- it's easier to test out e.g. the ResGroups CPU controller in
 conjunction with the UBC memory controller

- the additional kernel footprint of any of the competing resource
 management systems is substantially reduced, since it doesn't need
 to provide process grouping/containment, hence improving their
 chances of getting into the kernel

Possible TODOs include:

- define a convention for populating the per-container directories so
 that different subsystems don't clash with one another

- provide higher-level primitives (e.g. an easy interface to seq_file)
 for files registered by subsystems, or potentially convert to use configfs

Signed-off-by: Paul Menage <menage@google.com>

--

^ permalink raw reply	[flat|nested] 13+ messages in thread
* [PATCH 0/6]  Multi-hierarchy Process Containers
@ 2006-11-17 19:11 menage
  2006-11-17 19:12 ` [PATCH 2/6] Cpusets hooked into containers menage
  0 siblings, 1 reply; 13+ messages in thread
From: menage @ 2006-11-17 19:11 UTC (permalink / raw)
  To: akpm, pj, sekharan
  Cc: ckrm-tech, jlan, simon.derr, linux-kernel, mbligh, winget, rohitseth


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).

- The mount options passed when mounting a container filesystem
  indicate the set of controllers/subsystems that are wanted in the
  hierarchy - e.g. "mount -t container -o cpuset,numtasks container /foo"

- Default is to try to mount all subsystems

- if a hierarchy with the requested set of subsystems already exists
  then its superblock is reused

- otherwise (as long as all the requested subsystems are currently not
  in use in any hierarchy) a new hierarchy is created.

- hierarchies with more than one container (i.e. with any children of
  the root container) persist even when unmounted;

- /proc/containers shows current hierarchy/subsystem details

- /proc/<pid>/container shows one line for each active hierarchy

Other changes include:

- ported to 2.6.19-rc5 

- per-subsystem/per-container state is no longer just a void * - it
  has some state maintained by the container framework (to handle
  moving subsystems in and out of hierarchies when they are created/released)

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.

TODOs include:

- figuring out a nice way to handle release notifications now that
  there are multiple hierarchies

-------------------------------------

There have recently been various proposals floating around for
resource management/accounting subsystems in the kernel, including
Res Groups, User BeanCounters and others.  These all need the basic
abstraction of being able to group together multiple processes in an
aggregate, in order to track/limit the resources permitted to those
processes, and all implement this grouping in different ways.

Already existing in the kernel is the cpuset subsystem; this has a
process grouping mechanism that is mature, tested, and well documented
(particularly with regards to synchronization rules).

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.

The change is implemented in five stages plus an additional example patch:

1) extract the process grouping code from cpusets into a standalone system

2) remove the process grouping code from cpusets and hook into the
   container system

3) convert the container system to present a generic multi-hierarchy
   API, and make cpusets a client of that API

4) add a simple CPU accounting container subsystem as an example

5) add support for fork/exit callbacks iff some subsystem is interested in them

6) example of implementing ResGroups and its numtasks controller over
   generic containers - not intended to be applied with this patch set

The intention is that the various resource management efforts can also
become container clients, with the result that:

- the userspace APIs are (somewhat) normalised

- it's easier to test out e.g. the ResGroups CPU controller in
 conjunction with the UBC memory controller

- the additional kernel footprint of any of the competing resource
 management systems is substantially reduced, since it doesn't need
 to provide process grouping/containment, hence improving their
 chances of getting into the kernel


Signed-off-by: Paul Menage <menage@google.com>
--

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2006-11-17 19:14 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-10-20 18:38 [PATCH 0/6] Generic Process Containers menage
2006-10-20 18:38 ` [PATCH 1/6] Generic container system abstracted from cpusets code menage
2006-10-20 18:38 ` [PATCH 2/6] Cpusets hooked into containers menage
2006-11-06  6:34   ` [ckrm-tech] " Balbir Singh
2006-11-06 20:55     ` Paul Menage
2006-11-06 21:09       ` Paul Jackson
2006-11-06 21:22         ` Paul Menage
2006-11-07 14:06       ` Balbir Singh
2006-10-20 18:38 ` [PATCH 3/6] Add generic multi-subsystem API to containers menage
2006-10-20 18:38 ` [PATCH 4/6] Simple CPU accounting container subsystem menage
2006-10-20 18:38 ` [PATCH 5/6] Extension to container system to allow fork/exit callbacks menage
2006-10-20 18:38 ` [PATCH 6/6] Resource Groups over generic containers menage
2006-11-17 19:11 [PATCH 0/6] Multi-hierarchy Process Containers menage
2006-11-17 19:12 ` [PATCH 2/6] Cpusets hooked into containers menage

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome