Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757113Ab2E3ICl (ORCPT ); Wed, 30 May 2012 04:02:41 -0400 Received: from mail-we0-f174.google.com ([74.125.82.174]:35639 "EHLO mail-we0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756521Ab2E3ICh convert rfc822-to-8bit (ORCPT ); Wed, 30 May 2012 04:02:37 -0400 MIME-Version: 1.0 In-Reply-To: <4FC5D228.2070100@parallels.com> References: <4FC501E9.60607@parallels.com> <4FC506E6.8030108@parallels.com> <4FC52612.5060006@parallels.com> <4FC52CC6.7020109@parallels.com> <4FC530C0.30509@parallels.com> <20120530012955.GA4854@google.com> <4FC5D228.2070100@parallels.com> Date: Wed, 30 May 2012 17:02:35 +0900 X-Google-Sender-Auth: kiSkAbsQfUX0iYXsqnG1vRMZvvI Message-ID: Subject: Re: [PATCH v3 13/28] slub: create duplicate cache From: Tejun Heo To: Glauber Costa Cc: Christoph Lameter , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, kamezawa.hiroyu@jp.fujitsu.com, Li Zefan , Greg Thelen , Suleiman Souhlal , Michal Hocko , Johannes Weiner , devel@openvz.org, David Rientjes , Pekka Enberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2013 Lines: 48 Hello, Glauber. On Wed, May 30, 2012 at 4:54 PM, Glauber Costa wrote: > On 05/30/2012 05:29 AM, Tejun Heo wrote: >> >> The two goals for cgroup controllers that I think are important are >> proper (no, not crazy perfect but good enough) isolation and an >> implementation which doesn't impact !cg path in an intrusive manner - >> if someone who doesn't care about cgroup but knows and wants to work >> on the subsystem should be able to mostly ignore cgroup support. ?If >> that means overhead for cgroup users, so be it. > > > Well, my code in the slab is totally wrapped in static branches. They only > come active when the first group is *limited* (not even created: you can > have a thousand memcg, if none of them are kmem limited, nothing will > happen). Great, but I'm not sure why you're trying to emphasize that while my point was about memory overhead and that it's OK to have some overheads for cg users. :) > After that, the cost paid is to find out at which cgroup the process is at. > I believe that if we had a faster way for this (like for instance: if we had > a single hierarchy, the scheduler could put this in a percpu variable after > context switch - or any other method), then the cost of it could be really > low, even when this is enabled. Someday, hopefully. > I will rework this series to try work more towards this goal, but at least > for now I'll keep duplicating the caches. I still don't believe that a loose > accounting to the extent Christoph proposed will achieve what we need this > to achieve. Yeah, I prefer your per-cg cache approach but do hope that it stays as far from actual allocator code as possible. Christoph, would it be acceptable if the cg logic is better separated? Thanks. -- tejun -- 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/