Re: [Libcg-devel] [RFC] How to handle the rules engine for cgroups

[Vivek Goyal]

On Fri, Jul 18, 2008 at 01:42:53PM +0530, Dhaval Giani wrote:

[..]
> > > > I think a wrapper (move to right group and calls exec) will run by user, not by admin.
> > > > In explicit placement, user knows what a type of application he/she launch.
> > > > 
> > > >  		/mnt/cgroup
> > > > 		|	|
> > > > 		gid1	gid2
> > > > 		|  |	|  |
> > > > 	      uid1 uid2	uid3 uid4
> > > > 	     |  |
> > > > 	 proj1  proj2
> > > > 
> > > 
> > > This is the easy to handle situation and I am hoping it will work in many
> > > of the cases.
> > 
> > This solution seems ok but this looks only one part of the storey. Here
> > the top level hierarchy is again user based(gid/uid). What if admin
> > wants to manage the system resources per application basis? Say a big
> > server in a university is being shared by everyone in the university for
> > only 3 application
> > 1. http server
> > 2. browsing
> > 3. computing
> > In case the admin wants the system to be always available for computing,
> > how should he utilize cgroups for managing the server resources among
> > these applications ?
> > Isn't such scenarios on the priority now?
> 
> We only have FS permissions to play around with. Therefore any hierarchy
> we come up with will be uid/gid based. Such scenarios will be handled by
> the administrator by ensuring the correct permissions are set for the
> cgroup.
> 
> > 
> > > 
> > > Currently I am writting a patch for libcg which allows querying the
> > > destination cgroup based on uid/gid and libcg will also migrate the
> > > application there. I am also writing a pam plugin which will move
> > > all the login sessions to respective cgroup (as mentioned by rule file).
> > > Will also modify "init" so that all the system services to into cgroup
> > > belonging to root.
> > > 
> > > Once user is logged in and running into his resource group, he can manage
> > > further subgroups at his own based on his application requirements (as you
> > > mentioned proj1 and proj2 here).
> > > 
> > > > [uid1/gid1]% newtask.sh proj1app
> > > > ... proj1app run under /mnt/cgroup/gid1/uid1
> > > > 
> > > 
> > > Yes, so if a user does not specifically launch an application targetted
> > > for a particular cgroup, then it will run into default group for that
> > > user (as specified by rule file). In this case under /mnt/cgroup/gid1/uid1.
> > So in this user based approach if admin wants to run 4 major
> > applications each one requiring say 15% cpu he needs to create 4
> > different gids? Creation of a user account just for running an
> > application does not look very flexible to me.
> > 
> 
> A lot of daemons run as specific users. Also its not a good idea to run
> daemons/servers as root users. They should run as users who have limited
> privileges. With such a model in place, Vivek's comments make sense and
> might be the right way to go ahead. 
> 

Even if admin is launching the applications/daemons and he wants to have
some control on the resources allocated on these daemons individually,
then he needs to just create four cgroups under his account and launch four
daemons in those four cgroups and control the resources.

				/mnt/cgroup
				|	  |
		        usergroup	  admingroup
		        |       |	  |   |    |
	              uid1    uid2	ser1 ser2  ser3	

Here all the "root" tasks go under /mnt/cgrop/admingroup. Now admin
has created three cgroups "ser1" "ser2" and "ser3". Now admin needs
to explicitly launch applications in right cgroup. Something like.

# newtask.sh -cg /mnt/cgroup/admingroup/ser1	appl1
# newtask.sh -cg /mnt/cgroup/admingroup/ser2	appl2
# newtask.sh -cg /mnt/cgroup/admingroup/ser3	appl3

So admin need not to create separate accounts if services have been
launched by admin. He just needs to launch the services in right cgroup
by using the command line utility, specifying destination cgroup.
(To be written).

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