From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753765AbYKBLrt (ORCPT ); Sun, 2 Nov 2008 06:47:49 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753147AbYKBLrk (ORCPT ); Sun, 2 Nov 2008 06:47:40 -0500 Received: from E23SMTP01.au.ibm.com ([202.81.18.162]:44299 "EHLO e23smtp01.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753133AbYKBLrj (ORCPT ); Sun, 2 Nov 2008 06:47:39 -0500 Message-ID: <490D931B.8000200@linux.vnet.ibm.com> Date: Sun, 02 Nov 2008 17:16:35 +0530 From: Balbir Singh Reply-To: balbir@linux.vnet.ibm.com Organization: IBM User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: KAMEZAWA Hiroyuki CC: linux-mm@kvack.org, YAMAMOTO Takashi , Paul Menage , lizf@cn.fujitsu.com, linux-kernel@vger.kernel.org, Nick Piggin , David Rientjes , Pavel Emelianov , Dhaval Giani , Andrew Morton Subject: Re: [mm] [PATCH 2/4] Memory cgroup resource counters for hierarchy References: <20081101184812.2575.68112.sendpatchset@balbir-laptop> <20081101184837.2575.98059.sendpatchset@balbir-laptop> <20081102144237.59ab5f03.kamezawa.hiroyu@jp.fujitsu.com> <490D3F72.9040408@linux.vnet.ibm.com> <20081102145641.a15f5bb3.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: <20081102145641.a15f5bb3.kamezawa.hiroyu@jp.fujitsu.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org KAMEZAWA Hiroyuki wrote: > On Sun, 02 Nov 2008 11:19:38 +0530 > Balbir Singh wrote: > >> KAMEZAWA Hiroyuki wrote: >>> On Sun, 02 Nov 2008 00:18:37 +0530 >>> Balbir Singh wrote: >>> >>>> Add support for building hierarchies in resource counters. Cgroups allows us >>>> to build a deep hierarchy, but we currently don't link the resource counters >>>> belonging to the memory controller control groups, which are linked in >>>> cgroup hiearchy. This patch provides the infrastructure for resource counters >>>> that have the same hiearchy as their cgroup counter parts. >>>> >>>> These set of patches are based on the resource counter hiearchy patches posted >>>> by Pavel Emelianov. >>>> >>>> NOTE: Building hiearchies is expensive, deeper hierarchies imply charging >>>> the all the way up to the root. It is known that hiearchies are expensive, >>>> so the user needs to be careful and aware of the trade-offs before creating >>>> very deep ones. >>>> >>> ...isn't it better to add "root_lock" to res_counter rather than taking >>> all levels of lock one by one ? >>> >>> spin_lock(&res_counter->hierarchy_root->lock); >>> do all charge/uncharge to hierarchy >>> spin_unlock(&res_counter->hierarchy_root->lock); >>> >>> Hmm ? >>> >> Good thought process, but that affects and adds code complexity for the case >> when hierarchy is enabled/disabled. It is also inefficient, since all charges >> will now contend on root lock, in the current process, it is step by step, the >> contention only occurs on common parts of the hierarchy (root being the best case). >> > > Above code's contention level is not different from "only root no children" case. > Just inside-lock is heavier. Yes, correct! I think the approach in the patches is better. -- Balbir