Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754556Ab2E2RIF (ORCPT ); Tue, 29 May 2012 13:08:05 -0400 Received: from mx2.parallels.com ([64.131.90.16]:59292 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751341Ab2E2RID (ORCPT ); Tue, 29 May 2012 13:08:03 -0400 Message-ID: <4FC501E9.60607@parallels.com> Date: Tue, 29 May 2012 21:05:45 +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> 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: 2368 Lines: 57 On 05/29/2012 08:05 PM, Christoph Lameter wrote: > On Tue, 29 May 2012, Glauber Costa wrote: > >> Accounting pages seems just crazy to me. If new allocators come in the future, >> organizing the pages in a different way, instead of patching it here and >> there, we need to totally rewrite this. > > Quite to the contrary. We could either pass a THIS_IS_A_SLAB page flag to > the page allocator call or have a special call that does the accounting > and then calls the page allocator. The code could be completely in > cgroups. There would be no changes to the allocators aside from setting > the flag or calling the alternate page allocator functions. Again: for the page allocation itself, we could do it. (maybe we still can, keeping the rest of the approach, so as to simplify that particular piece of code, and reduce the churn inside the cache - I am all for it) But that only solves the page allocation part. I would still need to make sure the caller is directed to the right page. >>> Why do you need to increase the refcount? You made a full copy right? >> >> Yes, but I don't want this copy to go away while we have other caches around. > > You copied all metadata so what is there that you would still need should > the other copy go away? Well, consistency being one, because it sounded weird to have the parent cache being deleted while the kids are around. You wouldn't be able to reach them, for once. But one can argue that if you deleted the cache, why would you want to ever reach it? I can try to remove the refcount. > >> So, in the memcg internals, I used a different reference counter, to avoid >> messing with this one. I could use that, and leave the original refcnt alone. >> Would you prefer this? > > The refcounter is really not the issue. > > I am a bit worried about the various duplicate features here and there. > The approach is not tightened down yet. Well, I still think that duplication of the structure is better - a lot less intrusive - than messing with the cache internals. I will try to at least have the page accounting done in a consistent way. How about that? -- 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/