Rik van Riel wrote:

>On Wed, 28 Jan 2004, Shailabh Nagar wrote:
>
>
>>Incidentally, the website ckrm.sf.net has been updated a bit to make the 
>>second version of the API/core (C01) more visible.
>>
>
>Cool.
>
>OTOH, Stephen Tweedie just convinced me to also look at another
>model of doing resource management configuration ;)
>
>Basically resource groups would be directories in a special
>filesystem. Users would be to create new hierarchical resource
>groups in directories they have write access to and call a
>system call to change into a new resource group, provided
>they have execute permission on that directory.
>
>Shell scripts can easily change themselves into a new resource
>group, while applications linked to the PAM library can be moved
>into their resource group using the pam library.
>
>I am going to look into this in more detail before I can decide
>whether or not it's completely feasible, but the fact that the
>user can subdivide their own resources easily is definately a
>big plus over the "root preconfigures all resources" model...
>
>I'll let you know where it goes.  The resource usage enforcement
>will be the same in both models anyway.
>

Hi Rik,

Here's a writeup of a revised design for CKRM that we've been thinking
about.  It takes the state thats on the CKRM website a bit further by
integrating the inbound network control (we'd described the latter at
OLS'03 but not completely integrated with CKRM) and putting some more
thought into the API.

As Hubertus mentioned, your ideas on hierarchical classes and a
filesystem-based interface sound useful. Please review the document to
see how we could come up with a uniform API and design for class-based
resource management.

CKRM is not wedded to any API. We're only interested in trying to
evolve a solution that

- preserves independence of the classification mechanism and the
resource controllers

- integrates/allows inbound network control. This presents a bit of a
  challenge as inbound network classes do not fit neatly into
  the task group concept but it does fit in with what a user of CKRM
  would like to do (control inbound network
  connections/bandwidth by some user-defined grouping)

- implements mechanisms and leaves policy to users:  This sounds like a
  mantra from an OS textbook but its really important here so that
  resource management middleware (besides sysadmins) can make
  use of CKRM APIs effectively.

- causes minimal (zero would be nice) performance impact to users who
don't care for such control

I'm pretty sure those are all desirable attributes for your design too
so we should be able to come up with something common. As you mentioned, 
the control
mechanisms won't change too much if the semantics of hierarchical 
classes are kept simple.

Looking forward to your writeup and comments.

-- Shailabh