linux-kernel - Re: [RFC] [PATCH -mm] cgroup: uid-based rules to add processes efficiently in the right cgroup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/