[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <48B41B8A.70301@sun.com>
Date: Tue, 26 Aug 2008 11:04:42 -0400
From: David Collier-Brown <davecb@....com>
To: balbir@...ux.vnet.ibm.com
Cc: Vivek Goyal <vgoyal@...hat.com>, Paul Menage <menage@...gle.com>,
righi.andrea@...il.com,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
linux kernel mailing list <linux-kernel@...r.kernel.org>,
Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
Kazunaga Ikeno <k-ikeno@...jp.nec.com>,
Morton Andrew Morton <akpm@...ux-foundation.org>,
Thomas Graf <tgraf@...hat.com>,
Ulrich Drepper <drepper@...hat.com>,
Steve Olivieri <solivier@...hat.com>
Subject: Re: [RFC] [PATCH -mm] cgroup: uid-based rules to add processes
efficiently in the right cgroup
Balbir Singh wrote:
> Applications that really care about moving should use cgroup_attach_task* and
> move back otherwise with cgrules parsing turned off.
>
> I see control as a two level hierarchy, automatic and controlled, how do we make
> sure that they don't conflict is something I have not thought about yet.
[...]
> Hmm... I wonder if we are providing too many knobs. Can't we do something simpler?
Solaris doesn't try to change cgroup ("project") on a setuid call, assuming
the program is in the proper cgroup initially. For most cases this is
trivially true under the very simple default rules, and for the rest one
can create a rule or a startup script that sets it with newtask".
The Sun default is
$ cat /etc/project
system:0::::
user.root:1::::
noproject:2::::
default:3::::
group.staff:10::::
Which means that root users are distinguished from users in
the staff group, and they are distinguished from daemons
and everyone else.
Personally, I add
user.davecb:101::davecb::
bg:100:Background jobs:davecb::
which puts me in a separate cgroup, and provides another one
for me to put background tasks into. The latter allows
me to keep them from reducing the interactive performance of
my laptop.
In practice, this looks like:
$ prstat -J
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
695 davecb 52M 38M sleep 1 0 0:01:41 2.4% Xsun/1
1025 davecb 150M 88M sleep 59 0 0:04:25 1.9% mozilla-bin/5
926 davecb 73M 16M sleep 33 0 0:00:11 1.3% gnome-terminal/2
1067 davecb 6232K 5224K cpu0 54 0 0:00:00 0.3% prstat/1
918 davecb 66M 15M sleep 59 0 0:00:15 0.2% metacity/1
956 davecb 67M 13M sleep 59 0 0:00:04 0.1% gnome-netstatus/1
958 davecb 66M 12M sleep 59 0 0:00:02 0.1% mixer_applet2/1
931 root 2112K 1240K sleep 59 0 0:00:01 0.0% rpc.rstatd/1
954 davecb 68M 15M sleep 57 0 0:00:06 0.0% wnck-applet/1
920 davecb 71M 17M sleep 59 0 0:00:04 0.0% gnome-panel/1
943 davecb 1408K 1136K sleep 57 0 0:00:00 0.0% ksh/1
871 davecb 3984K 2656K sleep 59 0 0:00:01 0.0% xscreensaver/1
916 davecb 10M 4936K sleep 59 0 0:00:01 0.0% gnome-smproxy/1
924 davecb 67M 13M sleep 59 0 0:00:01 0.0% gnome-perfmeter/1
116 root 4352K 1168K sleep 59 0 0:00:00 0.0% lp/1
PROJID NPROC SIZE RSS MEMORY TIME CPU PROJECT
101 32 1050M 352M 71% 0:07:02 6.4% user.davecb
0 49 192M 73M 15% 0:00:22 0.1% system
3 5 33M 11M 2.2% 0:00:00 0.0% default
I'm using 6.4% of the CPU, the daemons are using 0.1% and even a
terribly CPU-heavy program will not starve the others of resources.
So for me, cgroups/projects are golden, and the simplest rules
suffice.
--dave
--
David Collier-Brown | Always do right. This will gratify
Sun Microsystems, Toronto | some people and astonish the rest
davecb@....com | -- Mark Twain
cell: (647) 833-9377, bridge: (877) 385-4099 code: 506 9191#
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists