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

[Paul Jackson <pj@sgi.com>]

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:
  http://www.uwsg.indiana.edu/hypermail/linux/kernel/0607.3/0896.html

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@sgi.com> 1.925.600.0401