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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20101201050129.GA5210@cr0.nay.redhat.com>
Date:	Wed, 1 Dec 2010 13:01:29 +0800
From:	Américo Wang <xiyou.wangcong@...il.com>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	Mike Galbraith <efault@....de>, 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 Tue, Nov 30, 2010 at 02:36:22PM -0500, Vivek Goyal wrote:
>
>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.
>
>Even if we prevent autogroup task from being visible in cpu controller
>root group, then comes the question what happens if cpu and some other
>controller is comounted. Say cpuset. Now in that case will task be 
>visible in root group task file and can one operate on that. Now showing
>up there does not make much sense as task should still be controllable
>by other controllers and its policies.
>
>So yes, creating a /proc/<pid>/autogroup is dirt cheap and makes the life
>easier in terms of implementation of this patch and it should work well.
>But it is also a new user interface which does not sound too extensible and
>does not seem to cooperate well with cgroup interface.
>
>It also introduces this new notion of niceness for task groups which is sort
>of equivalent to cpu.shares in cpu controller. First of all why should we
>not stick to shares notion even for autogroup. Even if we introduce the notion
>of niceness for groups, IMHO, it should be through cgroup interface instead of
>group niceness for autogroup and shares/weights for cgroup despite the
>fact that in the background they do similar things.
>

Hmm, maybe we can make AUTO_GROUP depend on !CGROUPS?

It seems that autogroup only uses 'struct task_group', no other cgroup things,
so I think that is reasonable and doable.
--
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/