lkml.org 
[lkml]   [2006]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC 3/5] sched: Add CPU rate hard caps
    Hi, Kirill,

    Kirill Korotaev wrote:
    >> Do you have any documented requirements for container resource
    >> management?
    >> Is there a minimum list of features and nice to have features for
    >> containers
    >> as far as resource management is concerned?
    >
    > Sure! You can check OpenVZ project (http://openvz.org) for example of
    > required resource management. BTW, I must agree with other people here
    > who noticed that per-process resource management is really useless and
    > hard to use :(

    I'll take a look at the references. I agree with you that it will be useful
    to have resource management for a group of tasks.

    >
    > Briefly about required resource management:
    > 1) CPU:
    > - fairness (i.e. prioritization of containers). For this we use SFQ like
    > fair cpu scheduler with virtual cpus (runqueues). Linux-vserver uses
    > tocken bucket algorithm. I can provide more details on this if you are
    > interested.

    Yes, any information or pointers to them will be very useful.

    > - cpu limits (soft, hard). OpenVZ provides only hard cpu limits. For
    > this we account the time in cycles. And after some credit is used do
    > delay of container execution. We use cycles as our experiments show that
    > statistical algorithms work poorly on some patterns :(
    > - cpu guarantees. I'm not sure any of solutions provide this yet.

    ckrm has a solution to provide cpu guarantees.

    I think as far as CPU resource management is concerned (limits or guarantees),
    there are common problems to be solved, for example

    1. Tracking when a limit or a gaurantee is not met
    2. Taking a decision to cap the group
    3. Selecting the next task to execute (keeping O(1) in mind)

    For the existing resource controller in OpenVZ I would be
    interested in the information on the kinds of patterns it does not
    perform well on and the patterns it performs well on.

    >
    > 2) disk:
    > - overall disk quota for container
    > - per-user/group quotas inside container
    >
    > in OpenVZ we wrote a 2level disk quota which works on disk subtrees.
    > vserver imho uses 1 partition per container approach.
    >
    > - disk I/O bandwidth:
    > we started to use CFQv2, but it is quite poor in this regard. First, it
    > doesn't prioritizes writes and async disk operations :( And even for
    > sync reads we found some problems we work on now...
    >
    > 3) memory and other resources.
    > - memory
    > - files
    > - signals and so on and so on.
    > For example, in OpenVZ we have user resource beancounters (original
    > author is Alan Cox), which account the following set of parameters:
    > kernel memory (vmas, page tables, different structures etc.), dcache
    > pinned size, different user pages (locked, physical, private, shared),
    > number of files, sockets, ptys, signals, network buffers, netfilter
    > rules etc.
    >
    > 4. network bandwidth
    > traffic shaping is already ok here.

    Traffic shaping is just for outgoing traffic right? How about incoming
    traffic (through the accept call)

    >

    These are a great set of requirements. Thanks for putting them together.


    >> Thinking a bit more along these lines, it would probably break O(1).
    >> But I guess a good
    >> algorithm can amortize the cost.
    >
    > this is the price to pay. but it happens quite rarelly as was noticed
    > already...
    >

    Yes, agreed.

    > Kirill
    >


    --

    Balbir Singh,
    Linux Technology Center,
    IBM Software Labs

    PS: I am also cc'ing ckrm-tech and srivatsa
    -
    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-06-01 10:41    [W:3.453 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site