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

From: Nick Piggin
Date: Fri Aug 04 2006 - 23:28:31 EST

Andrew Morton wrote:
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:

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

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

Sorry, I've been busy with offline stuff and won't be able to catch up with
emails until next week -- someone else might have already covered this.

But: I think we definitely agreed that a nice simple implementation and even
userspace API for grouping tasks would be a no-brainer.

I advocated implementing some simple controllers on top of such an interface
first, that people can start to put in some of their requirements, see if a
common controller framework should be created, look at what interfaces people
want for them.

I don't have a problem with CKRM as such, but I think there are other groups
with good approaches and the problem has been to get people working together.

SUSE Labs, Novell Inc.
Send instant messages to your online friends -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at