lkml.org 
[lkml]   [2006]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [ckrm-tech] [RFC] Resource Management - Infrastructure choices
    On Mon, Nov 06, 2006 at 12:23:44PM -0800, Paul Menage wrote:
    > > Secondly, regarding how separate grouping per-resource *maybe* usefull,
    > > consider this scenario.
    > >
    > > A large university server has various users - students, professors,
    > > system tasks etc. The resource planning for this server could be on these lines:
    > >
    > > CPU : Top cpuset
    > > / \
    > > CPUSet1 CPUSet2
    > > | |
    > > (Profs) (Students)
    > >
    > > In addition (system tasks) are attached to topcpuset (so
    > > that they can run anywhere) with a limit of 20%
    > >
    > > Memory : Professors (50%), students (30%), system (20%)
    > >
    > > Disk : Prof (50%), students (30%), system (20%)
    > >
    > > Network : WWW browsing (20%), Network File System (60%), others (20%)
    > > / \
    > > Prof (15%) students (5%)

    Lets say that network resource controller supports only one level
    hierarchy, and hence you can only split it as:

    Network : WWW browsing (20%), Network File System (60%), others (20%)

    > > Browsers like firefox/lynx go into the WWW network class, while (k)nfsd go
    > > into NFS network class.
    > >
    > > At the same time firefox/lynx will share an appropriate CPU/Memory class
    > > depending on who launched it (prof/student).
    > >
    > > If we had the ability to write pids directly to these resource classes,
    > > then admin can easily setup a script which receives exec notifications
    > > and depending on who is launching the browser he can
    > >
    > > # echo browser_pid > approp_resource_class
    > >
    > > With your proposal, he now would have to create a separate container for
    > > every browser launched and associate it with approp network and other
    > > resource class. This may lead to proliferation of such containers.
    >
    > Or create one container per combination (so in this case four,
    > prof/www, prof/other, student/www, student/other) - then processes can
    > be moved between the containers to get the appropriate qos of each
    > type.
    >
    > So the setup would look something like:
    >
    > top-level: prof vs student vs system, with new child nodes for cpu,
    > memory and disk, and no new node for network
    >
    > second-level, within the prof and student classes: www vs other, with
    > new child nodes for network, and no new child nodes for cpu.
    >
    > In terms of the commands to set it up, it might look like (from the top-level)
    >
    > echo network > inherit
    > mkdir prof student system
    > echo disk,cpu,memory > prof/inherit
    > mkdir prof/www prof/other
    > echo disk,cpu,memory > student/inherit
    > mkdir student/www student/other

    By these commands, we would forcibly split the WWW bandwidth of 20%
    between prof/www and student/www, when it was actually not needed (as
    per the new requirement above). This forced split may be fine for a renewable
    resource like network bandwidth, but would be inconvenient for something like
    RSS, disk quota etc.

    (I thought of a scheme where you can avoid this forced split by
    maintaining soft/hard links to resource nodes from the container nodes.
    Essentially each resource can have its own hierarchy of resource nodes.
    Each resource node provides allocation information like min/max shares.
    Container nodes point to one or more such resource nodes, implemented
    as soft/hard links. This will avoid the forced split I mentioned above.
    But I suspect we will run into atomicity issues again when modifying the
    container hierarchy).

    Essentially by restrictly ourselves to a single hierarchy, we loose the
    flexibility of "viewing" each resource usage differently (network by traffic,
    cpu by users etc).

    Coming to reality, I believe most work load management tools would be
    fine to live with this restriction. AFAIK containers can also use this
    model without much loss of flexibility. But if you are considering long term
    user-interface stability, then this is something I would definitely
    think hard about.

    --
    Regards,
    vatsa
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-11-10 16:01    [W:5.569 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site