On Sun, Aug 17, 2008 at 12:33:31PM +0200, Andrea Righi wrote:
quoted text
> The problem of placing tasks in respective cgroups seems to be correctly
> addressed by userspace lib wrappers or classifier daemons [1].
> 
> However, this is an attempt to implement an in-kernel classifier.
> 
> [ I wrote this patch for a "special purpose" environment, where a lot of
> short-lived processes belonging to different users are spawned by
> different daemons, so the main goal here would be to remove the dealy
> needed by userspace classification and place the tasks in the right
> cgroup at the time they're created. This is just an ugly hack for now
> and it works only for uid-based rules, gid-based rules could be
> implemented in a similar way. ]
> 

Hi  Andrea,

Recently I introduced the infrastructure in libcgroup to handle
the task placement issue based on uid and gid rules. This is what I did.

- Introduced two new APIs in libcgroup to place the task in right cgroup.
	- cgroup_change_cgroup_uid_gid
		Pleces the task in destination cgroup based on uid/gid
		rules specified in /etc/cgrules.conf
	- cgroup_change_cgroup_path
		Puts the task into the cgroup specified by caller

- Provided two command line tools (cgexec and cgclassify) to perform
  various process placement related tasks.
	- cgexec
		A tool to launch a task in user specfied cgroup
	- cgclassify
		A tool to re-classify already running tasks.

- Wrote a pam plugin so that tasks are placed in right user groups upon
  login or reception of other services which take pam's help.

- Currently work is in progress for a user space daemon which will 
  automatically place the tasks based on notifications.

For your environment, where delay is unbearable, I think you can modify
the daemon to use libcgroup to place the forked task in right cgroup
before actually executing it. Once the task has been placed in right
cgroup, exec() will be called.

We have been doing all the user space development on following mailing
list.

https://lists.sourceforge.net/lists/listinfo/libcg-devel

Latest patches which got merged in libcgroup, are here.

http://sourceforge.net/mailarchive/forum.php?thread_name=20080813171720.108005557%40re...

It is accompanied with a decent README file for design details and for
how to use it.

I think modifying the daemon to make use of libcgroup is the right way
to handle this issue than duplicating the infrastructure in user space
as well as kernel space.

Thanks
Vivek
--
unsubscribe notice
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/