Messages in this thread | | | Date | Thu, 3 Jul 2008 10:19:57 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: [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
| |