From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753163AbYKBFtz (ORCPT ); Sun, 2 Nov 2008 01:49:55 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751982AbYKBFtq (ORCPT ); Sun, 2 Nov 2008 01:49:46 -0400 Received: from E23SMTP01.au.ibm.com ([202.81.18.162]:39057 "EHLO e23smtp01.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751871AbYKBFtq (ORCPT ); Sun, 2 Nov 2008 01:49:46 -0400 Message-ID: <490D3F72.9040408@linux.vnet.ibm.com> Date: Sun, 02 Nov 2008 11:19:38 +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> In-Reply-To: <20081102144237.59ab5f03.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 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). Thanks for the comments, -- Balbir