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]

Date:	Tue, 08 Aug 2006 11:19:40 +0400
From:	Kirill Korotaev <dev@...ru>
To:	rohitseth@...gle.com
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

>>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.
In this case you can't plan your resources, can't say which one consumes
more memory and can't select the worst container to kill and many other drawbacks.

Kirill

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