About this list Date view Thread view Subject view Author view Attachment view

From: Sam Vilain (sam_at_vilain.net)
Date: Fri 07 Nov 2003 - 20:43:54 GMT

On Fri, 07 Nov 2003 19:46, Chandra Seetharaman wrote;

> But, integrating CKRM and vserver might not add more value and
> provide unneccessary burden for somebody that want sees value in
> only one of them.

OK, I see your point.

> With CKRM design this can be easily done. RBCE can be extended to
> allow rules that can be defined to classify tasks based on their
> security context. And by limiting the resource shares used by each
> class, one can control how much resource a particular security
> context uses.

OK then. In that case, it probably makes more sense if we (vserver)
don't bother with doing any of the resource management stuff for our
2.6.0 port, if CKRM is going to provide a greater feature set, but
instead focus on integrating documentation, examples and performing

We currently have implementations for resource control over:

  1. cpu - as referred to before:

> > 2. http://www.vilain.net/linux/ctx/split-2.4.22-ac4-c17g2/

    have you compared this CPU scheduling with your own
    implementation? I didn't see any patch to sched.c in your core
    patch, I assume that it is packaged seperately. Do you have a
    pre-release patch that I can look at to see how the `pros' :) do

  2. disk limits per vserver:


    we've also got a quota-per-context patch, but I don't know whether
    or not you care about that.

  3. memory limits:

    Herbert, correct me if I'm wrong, but the most up to date version
    for the plain kernel is:


    There's also a version for Rik van Riel's VM subsystem (rmap), and
    I'm the wrong person to ask what the sitation is re: which VM is
    in 2.6.0, where the memory limits patch is for rmap. All I know
    is that with the rmap patch, we can limit the RSS per vserver.
    Perhaps Rik can `take it away' here and explain what the situation
    is :-)

  4. network limits:

    not part of vserver - but I've used iptables in the past for this.

Have you got implementations for all these parts too?

Sam Vilain, sam_at_vilain.net

A complex system that works is invariably found to have evolved from a simple system that worked. - anon.

_______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Fri 07 Nov 2003 - 20:45:36 GMT by hypermail 2.1.3