Re: [RFC, PATCH 0/5] Going forward with Resource Management - A cpu controller

On Fri, 4 Aug 2006 10:37:53 +0530
Srivatsa Vaddagiri <vatsa@xxxxxxxxxx> wrote:

Resource management has been talked about quite extensively in the
past, more recently in the context of containers. The basic requirement
here is to provide isolation between *groups* of task wrt their use
of various resources like CPU, Memory, I/O bandwidth, open file-descriptors etc.

Different maintainers have however expressed different opinions over the need to
complicate the kernel to meet this need, especially since it involves core
kernel code like the resource schedulers.

A BoF was hence held at OLS this year to come to a consensus on the minimum
requirements of a resource management solution for Linux kernel. Some notes
taken at the BoF are posted here:

http://www.uwsg.indiana.edu/hypermail/linux/kernel/0607.3/0896.html

An important consensus point of the BoF seemed to be "focus on real
controllers more, preferably memory first, using some simple interface
and task grouping mechanism".

ug, I didn't know this. Had I been there (sorry) I'd have disagreed with
this whole strategy.

I thought the most recently posted CKRM core was a fine piece of code. It
provides the machinery for grouping tasks together and the machinery for
establishing and viewing those groupings via configfs, and other such
common functionality. My 20-minute impression was that this code was an
easy merge and it was just awaiting some useful controllers to come along.

And now we've dumped the good infrastructure and instead we've contentrated
on the controller, wired up via some imaginative ab^H^Hreuse of the cpuset
layer.

I wonder how many of the consensus-makers were familiar with the
contemporary CKRM core?

In going forward, following points will need to be addressed:

- Grouping and interface
- What mechanism to use for grouping tasks and
for specifying task-group resource usage limits?

ckrm ;)

- Design of individual resource controllers like memory and cpu

Right. We won't be controlling memory, numtasks, disk, network etc
controllers via cpusets, will we?


This patch series is an attempt to take forward the design discussion of a
CPU controller.

That's good. The controllers are the sticking point. Most especially the
memory controller.

For simplicity and convenience, cpuset has been chosen as the means to group
tasks here, primarily because cpuset already exists in the kernel and also
perhaps resource container definition should be unique only inside a cpuset.


Correct me if I'm wrong, but a cpuset isn't the appropriate machinery to be
using to group tasks.

And if this whole resource-control effort is to end up being successful, it
should have as core infrastructure a flexible, appropriate and uniform way
of grouping tasks together and of getting data into and out of those
aggregates. We already have that, don't we?



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

Relevant Pages

  • Re: [RFC, PATCH 0/5] Going forward with Resource Management - A cpu controller
    ... provides the machinery for grouping tasks together and the machinery for ... easy merge and it was just awaiting some useful controllers to come along. ... should task-group resource container manage all the resources as a whole? ...
    (Linux-Kernel)
  • Re: [RFC, PATCH 0/5] Going forward with Resource Management - A cpu controller
    ... easy merge and it was just awaiting some useful controllers to come along. ... CPUset was used in this patch series primarily because it ... We had be more than happy to work with the ckrm core which was posted last. ... of grouping tasks together and of getting data into and out of those ...
    (Linux-Kernel)
  • [RFC] Revised CKRM release
    ... The Class-based Resource Management project is happy to release the ... A filesystem-based user interface, proposed by Rik van Riel, to ... useful for controlling groups of sockets. ... Resource controllers are now explicitly associated with a ...
    (Linux-Kernel)
  • Re: [ckrm-tech] [RFC] Resource Management - Infrastructure choices
    ... mount -t cpuset cpuset /dev/cpuset ... resource group controller to a container hierarchy. ... multiple controllers to a common task container hierarchy. ... I would expect one kernel build CONFIG option for each controller type. ...
    (Linux-Kernel)
  • Re: Cluster Resource replacing physical server
    ... Controllers had all been synchronized with the each other, ... Delete original computer account and replicate to all domain ... Create cluster resource ... Directory and the Kerberos authentication is not enabled for the ...
    (microsoft.public.sqlserver.clustering)