linux-kernel - Re: [RFC] CPU hard limits

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:	Fri, 5 Jun 2009 02:48:36 -0700
From:	Paul Menage <menage@...gle.com>
To:	balbir@...ux.vnet.ibm.com
Cc:	bharata@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org,
	Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>,
	Gautham R Shenoy <ego@...ibm.com>,
	Srivatsa Vaddagiri <vatsa@...ibm.com>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Pavel Emelyanov <xemul@...nvz.org>,
	Avi Kivity <avi@...hat.com>, kvm@...r.kernel.org,
	Linux Containers <containers@...ts.linux-foundation.org>,
	Herbert Poetzl <herbert@...hfloor.at>
Subject: Re: [RFC] CPU hard limits

On Fri, Jun 5, 2009 at 2:36 AM, Balbir Singh<balbir@...ux.vnet.ibm.com> wrote:
>
> The important scenario I have is adding and removing groups.
>
> Consider 10 cgroups with shares of 10 each, what if 5 new are created
> with the same shares? We now start getting 100/15, even though we did
> not change our shares.

Are you assuming that arbitrary users can create new cgroups whenever
they like, with whatever shares they like? In that situation, how
would you use hard limits to provide guarantees? Presumably if the
user could create a cgroup with an arbitrary share, they could create
one with an arbitrary hard limit too.

Can you explain a bit more about how you're envisaging cgroups being
created, and how their shares and hard limits would get set? I was
working on the assumption that (for any sub-tree of the CFS hierarchy)
there's a single managing entity that gets to decide the shares given
to the cgroups within that tree. That managing entity would be
responsible for ensuring that the shares given out allowed guarantees
to be met (or alternatively, that the probability of violating those
guarantees based on the shares given out was within some tolerance
threshold).

Paul
--
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/