linux-kernel - Re: [RFC, PATCH 0/5] Going forward with Resource Management

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: <1154975486.31962.40.camel@galaxy.corp.google.com>
Date:	Mon, 07 Aug 2006 11:31:26 -0700
From:	Rohit Seth <rohitseth@...gle.com>
To:	Kirill Korotaev <dev@...ru>
Cc:	"Martin J. Bligh" <mbligh@...igh.org>, vatsa@...ibm.com,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Andrew Morton <akpm@...l.org>, mingo@...e.hu,
	nickpiggin@...oo.com.au, sam@...ain.net,
	linux-kernel@...r.kernel.org, dev@...nvz.org, efault@....de,
	balbir@...ibm.com, sekharan@...ibm.com, nagar@...son.ibm.com,
	haveblue@...ibm.com, pj@....com, Andrey Savochkin <saw@...ru>
Subject: Re: [RFC, PATCH 0/5] Going forward with Resource Management - A
	cpu controller

On Mon, 2006-08-07 at 20:33 +0400, Kirill Korotaev wrote:
> >> we already have the code to account page fractions shared between 
> >> containers.
> >> Though, it is quite useless to do so for threads... Since this numbers 
> >> have no meaning (not a real usage)
> >> and only the sum of it will be a correct value.
> >>
> > THat sort of accounting poses various horrible problems, which is
> > why we steered away from it. If you share pages between containers
> > (presumably billing them equal shares per user), what happens
> > when you're already at your limit, and one of your sharer's exits?
> you come across your limit and new allocations will fail.
> BUT! IMPORTANT!
> in real life use case with OpenVZ we allow sharing not that much data across containers:
> vmas mapped as private, i.e. glibc and other libraries .data section
> (and .code if it is writable). So if you use the same glibc and other executables
> in the containers then your are charged only a fraction of phys memory used by it.
> This kind of sharing is not that huge (<< memory limits usually),
> so the situation you described is not a problem
> in real life (at least for OpenVZ).
> 

I think it is not a problem for OpenVZ because there is not that much of
sharing going between containers as you mentioned (btw, this least
amount of sharing is a very good thing).  Though I'm not sure if one has
to go to the extent of doing fractions with memory accounting.  If the
containers are set up in such a way that there is some sharing across
containers then it is okay to be unfair and charge one of those
containers for the specific resource completely.

-rohit

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