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

From: Paul Jackson
Date: Fri Aug 04 2006 - 01:57:01 EST

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

Odd ... I'm usually fairly keen to notice any use or abuse of cpuset stuff.

I didn't see any mention of 'cpuset' in:

I -do- see there:
* non-hierarchical,
* can't move tasks and
* syscall rather than file system API.

This all sounds like the polar antithesis of cpusets to me.

What did I miss, Andrew?

Before seeing your response, I was inclined to suggest that:
1) containers should have a good infrastructure, from the get go
(you just said the same thing of CKRM, as I read it), and
2) containers -should- look at a hierarchical pseudo file system
for this, as that seems like the 'natural' shape for
containers to take.
3) the syscall API, no hierarchy, 'simple' interface style
suggested for containers in the above notes sounded like
a really bad idea to me.

However, I was thinking of 'containers' when I thought this,
not of CKRM. And I haven't considered CKRM's infrastructure
in recent times. From what you say, it's worthy of serious
consideration now - good.

Perhaps (wild idea here) if 'containers' did lead us to looking
for a hierarchical pseudo file system interface, we could make
this common technology that both containers and the existing
cpusets could use, avoiding duplicating a chunk of vfs-aware
generic code that's now in kernel/cpuset.c to provide the file
system style interface. Cpusets would keep their existing API,
just share some generic vfs-aware code with these new containers.

I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@xxxxxxx> 1.925.600.0401
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