Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757035Ab2KBXGp (ORCPT ); Fri, 2 Nov 2012 19:06:45 -0400 Received: from mail-pb0-f46.google.com ([209.85.160.46]:60579 "EHLO mail-pb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750988Ab2KBXGn (ORCPT ); Fri, 2 Nov 2012 19:06:43 -0400 Date: Fri, 2 Nov 2012 16:06:38 -0700 From: Tejun Heo To: JoonSoo Kim Cc: Glauber Costa , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kamezawa.hiroyu@jp.fujitsu.com, Johannes Weiner , Michal Hocko , Christoph Lameter , Pekka Enberg , David Rientjes , Greg Thelen Subject: Re: [PATCH v6 00/29] kmem controller for memcg. Message-ID: <20121102230638.GE27843@mtj.dyndns.org> References: <1351771665-11076-1-git-send-email-glommer@parallels.com> <20121101170454.b7713bce.akpm@linux-foundation.org> <50937918.7080302@parallels.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1409 Lines: 37 Hey, Joonsoo. On Sat, Nov 03, 2012 at 04:25:59AM +0900, JoonSoo Kim wrote: > I am worrying about data cache footprint which is possibly caused by > this patchset, especially slab implementation. > If there are several memcg cgroups, each cgroup has it's own kmem_caches. > When each group do slab-intensive job hard, data cache may be overflowed easily, > and cache miss rate will be high, therefore this would decrease system > performance highly. It would be nice to be able to remove such overhead too, but the baselines for cgroup implementations (well, at least the ones that I think important) in somewhat decreasing priority are... 1. Don't over-complicate the target subsystem. 2. Overhead when cgroup is not used should be minimal. Prefereably to the level of being unnoticeable. 3. Overhead while cgroup is being actively used should be reasonable. If you wanna split your system into N groups and maintain memory resource segregation among them, I don't think it's unreasonable to ask for paying data cache footprint overhead. So, while improvements would be nice, I wouldn't consider overheads of this type as a blocker. 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/