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:	Wed, 17 Nov 2010 16:01:56 +0100
From:	Lennart Poettering <mzxreary@...inter.de>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	Ted Ts'o <tytso@....edu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Dhaval Giani <dhaval.giani@...il.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Mike Galbraith <efault@....de>,
	Oleg Nesterov <oleg@...hat.com>,
	Markus Trippelsdorf <markus@...ppelsdorf.de>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>
Subject: Re: [RFC/RFT PATCH v3] sched: automated per tty task groups

On Wed, 17.11.10 09:57, Vivek Goyal (vgoyal@...hat.com) wrote:

> Being able to specify cgroup name/path is a good idea. That way one can
> make use of cgroup hierarchy also.
> 
> Thinking more about opt-in vs opt-out issue. Generally cgroups provide
> some kind of isolation between application groups and in the process
> can be somewhat expensive. More memory allocation, more accounting overhead
> and for CFQ block controller it can also mean additional idling and can result
> in overall reduced throughput.
> 
> Keeping that in mind, is it really a good idea to launch each application
> in a separate group. Will it be better to let user decide if the
> application should be launched in a separate cgroup? 
> 
> The flip side is that how many people will really know about the functionality
> and will really launch application in a separate group. And may be it is
> a good idea to put everybody in a seprate cgroup by default even it means
> some cost so that if a application starts consuming too much of resources
> (make -j64), then its impact on rest of the groups can be contained.
> 
> I really don't have strong inclination for one over other. Just thinking
> loud...

I wouldn't be too concerned here. It's not that we end up with 1000s of
groups here. It's way < 40 or in the end, for a single user
machine. Which I think isn't that bad.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ