linux-kernel - Re: [PATCH v4] sched: automated per session task groups

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 1 Dec 2010 09:55:56 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Mike Galbraith <efault@....de>
Cc:	Paul Turner <pjt@...gle.com>, Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4] sched: automated per session task groups

On Wed, Dec 01, 2010 at 06:57:48AM +0100, Mike Galbraith wrote:

[..]
> 
> > - I am doing some testing with the patch and w.r.t. cgroup interface some
> >   things don't seem right.
> > 
> >   I have applied your patch and enabled CONFIG_AUTO_GROUP. Now I boot
> >   into the kernel and open a new ssh connection to the machine. 
> > 
> >   # echo $$
> >     3555
> >   # cat /proc/3555/autogroup
> >     /autogroup-63 nice 0
> > 
> >   IIUC, task 3555 has been moved into an autogroup. Now I mount the cpu
> >   controller and this task is visible in root cgroup.
> > 
> >   # mount -t cgroup -o cpu none /cgroup/cpu
> >   # cat /cgroup/cpu/tasks | grep 3555
> >     3555
> > 
> >   First of all this gives user a wrong impression that task 3555 is in
> >   root cgroup.
> 
> It is in the root cgroup.  It is not in the root autogroup is not
> auto-cgroups group.
> 
> >   Now I create a child group test1 and move the task there and also change
> >   the weight/shares of the cgroup to 10240.
> > 
> >   # mkdir test1
> >   # echo 3555 > test1/tasks
> >   # echo 10240 > test1/cpu.shares
> >   # cat /proc/3555/cgroup
> >     3:cpu:/test1
> >   # cat /proc/3555/autogroup
> >     /autogroup-63 nice 0
> > 
> > So again, user will think that task is in cgroup test1 and is being
> > controlled by the respective weight but that's not the case.
> 
> It is the case here.
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  P COMMAND
>  7573 root      20   0  7996  340  256 R   50  0.0   3:35.86 3 pert
>  7572 root      20   0  7996  340  256 R   50  0.0   9:21.68 3 pert
> ...
> marge:/cgroups/test # echo 7572 > tasks
> marge:/cgroups/test # echo 4096 > cpu.shares
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  P COMMAND
>  7572 root      20   0  7996  340  256 R   80  0.0  10:06.92 3 pert
>  7573 root      20   0  7996  340  256 R   20  0.0   4:05.80 3 pert
> 
> When you move a task into a cgroup, it still has an autogroup
> association, as all tasks (processes actually) do, but it's not used.

Ok, so I got confused with the fact that after moving a task into a
cgroup it is still associated with an autogroup.

So IIUC, if a task is in root cgroup, then it would not necessarily be driven
by cpu.shares of root cgroup (as task could be in its own autogroup). But
if I move the task into a non-root cgroup, then it will for sure be
subjected to rules imposed by non-root cgroup cpu.shares. That's not too
bad.

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