Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755857Ab2E2U1z (ORCPT ); Tue, 29 May 2012 16:27:55 -0400 Received: from mx2.parallels.com ([64.131.90.16]:58886 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755167Ab2E2U1x (ORCPT ); Tue, 29 May 2012 16:27:53 -0400 Message-ID: <4FC530C0.30509@parallels.com> Date: Wed, 30 May 2012 00:25:36 +0400 From: Glauber Costa User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Christoph Lameter CC: , , , , Tejun Heo , Li Zefan , Greg Thelen , Suleiman Souhlal , Michal Hocko , Johannes Weiner , , David Rientjes , Pekka Enberg 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 X-Originating-IP: [188.255.67.70] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2543 Lines: 52 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/