From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx206.postini.com [74.125.245.206]) by kanga.kvack.org (Postfix) with SMTP id 1C47D6B0072 for ; Tue, 29 May 2012 16:27:55 -0400 (EDT) Message-ID: <4FC530C0.30509@parallels.com> Date: Wed, 30 May 2012 00:25:36 +0400 From: Glauber Costa MIME-Version: 1.0 Subject: Re: [PATCH v3 13/28] slub: create duplicate cache References: <1337951028-3427-1-git-send-email-glommer@parallels.com> <1337951028-3427-14-git-send-email-glommer@parallels.com> <4FC4F1A7.2010206@parallels.com> <4FC501E9.60607@parallels.com> <4FC506E6.8030108@parallels.com> <4FC52612.5060006@parallels.com> <4FC52CC6.7020109@parallels.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Christoph Lameter Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, kamezawa.hiroyu@jp.fujitsu.com, Tejun Heo , Li Zefan , Greg Thelen , Suleiman Souhlal , Michal Hocko , Johannes Weiner , devel@openvz.org, David Rientjes , Pekka Enberg On 05/30/2012 12:21 AM, Christoph Lameter wrote: > On Wed, 30 May 2012, Glauber Costa wrote: > >> Well, I'd have to dive in the code a bit more, but that the impression that >> the documentation gives me, by saying: >> >> "Cpusets constrain the CPU and Memory placement of tasks to only >> the resources within a task's current cpuset." >> >> is that you can't allocate from a node outside that set. Is this correct? > > Basically yes but there are exceptions (like slab queues etc). Look at the > hardwall stuff too that allows more exceptions for kernel allocations to > use memory from other nodes. > >> So extrapolating this to memcg, the situation is as follows: >> >> * You can't use more memory than what you are assigned to. >> * In order to do that, you need to account the memory you are using >> * and to account the memory you are using, all objects in the page >> must belong to you. > > Cpusets work at the page boundary and they do not have the requirement you > are mentioning of all objects in the page having to belong to a certain > cpusets. Let that go and things become much easier. > >> With a predictable enough workload, this is a recipe for working around the >> very protection we need to establish: one can DoS a physical box full of >> containers, by always allocating in someone else's pages, and pinning kernel >> memory down. Never releasing it, so the shrinkers are useless. > > Sure you can construct hyperthetical cases like that. But then that is > true already of other container like logic in the kernel already. > >> So I still believe that if a page is allocated to a cgroup, all the objects in >> there belong to it - unless of course the sharing actually means something - >> and identifying this is just too complicated. > > We have never worked container like logic like that in the kernel due to > the complicated logic you would have to put in. The requirement that all > objects in a page come from the same container is not necessary. If you > drop this notion then things become very easy and the patches will become > simple. I promise to look at that in more detail and get back to it. In the meantime, I think it would be enlightening to hear from other parties as well, specially the ones also directly interested in using the technology. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org