linux-kernel - [RFC][PATCH 0/4] Generic container system

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20060928104035.840699000@menage.corp.google.com>
Date:	Thu, 28 Sep 2006 03:40:35 -0700
From:	menage@...gle.com
To:	pj@....com, akpm@...l.org, ckrm-tech@...ts.sourceforge.net,
	mbligh@...gle.com, rohitseth@...gle.com, winget@...gle.com,
	dev@...ru, sekharan@...ibm.com
Cc:	linux-kernel@...r.kernel.org
Subject: [RFC][PATCH 0/4] Generic container system

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 four 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

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.

- support subsystem deregistering

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

---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/