lkml.org 
[lkml]   [2008]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] How to handle the rules engine for cgroups
    On Tue, 1 Jul 2008 15:11:26 -0400
    Vivek Goyal <vgoyal@redhat.com> wrote:

    > Hi,
    >
    > While development is going on for cgroup and various controllers, we also
    > need a facility so that an admin/user can specify the group creation and
    > also specify the rules based on which tasks should be placed in respective
    > groups. Group creation part will be handled by libcg which is already
    > under development. We still need to tackle the issue of how to specify
    > the rules and how these rules are enforced (rules engine).
    >
    > I have gathered few views, with regards to how rule engine can possibly be
    > implemented, I am listing these down.
    >
    > Proposal 1
    > ==========
    > Let user space daemon hanle all that. Daemon will open a netlink socket
    > and receive the notifications for various kernel events. Daemon will
    > also parse appropriate admin specified rules config file and place the
    > processes in right cgroup based on rules as and when events happen.
    >
    > I have written a prototype user space program which does that. Program
    > can be found here. Currently it is in very crude shape.
    >
    > http://people.redhat.com/vgoyal/misc/rules-engine-daemon/user-id-based-namespaces.patch
    >
    > Various people have raised two main issues with this approach.
    >
    > - netlink is not a reliable protocol.
    > - Messages can be dropped and one can loose message. That means a
    > newly forked process might never go into right group as meant.
    >
    > - How to handle delays in rule exectuion?
    > - For example, if an "exec" happens and by the time process is moved to
    > right group, it might have forked off few more processes or might
    > have done quite some amount of memory allocation which will be
    > charged to the wring group. Or, newly exec process might get
    > killed in existing cgroup because of lack of memory (despite the
    > fact that destination cgroup has sufficient memory).
    >
    Hmm, can't we rework the process event connector to use some reliable
    fast interface besides netlink ? (I mean an interface like eventpoll.)
    (Or enhance netlink ? ;)

    Because "a child inherits parent's" rule is very strong, I think the amount
    of events we have to check is much less than we get report. Can't we add some
    filter/assumption here ?

    BTW, the placement of proc_exec_connector() is not too late ? It seems memory for
    creating exec-image is charged to original group...

    Thanks,
    -Kame



    \
     
     \ /
      Last update: 2008-07-03 03:23    [W:4.316 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site