linux-kernel - Re: [mm] [PATCH 2/4] Memory cgroup resource counters for hierarchy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 02 Nov 2008 11:19:38 +0530
From:	Balbir Singh <balbir@...ux.vnet.ibm.com>
To:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
CC:	linux-mm@...ck.org, YAMAMOTO Takashi <yamamoto@...inux.co.jp>,
	Paul Menage <menage@...gle.com>, lizf@...fujitsu.com,
	linux-kernel@...r.kernel.org,
	Nick Piggin <nickpiggin@...oo.com.au>,
	David Rientjes <rientjes@...gle.com>,
	Pavel Emelianov <xemul@...nvz.org>,
	Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [mm] [PATCH 2/4] Memory cgroup resource counters for hierarchy

KAMEZAWA Hiroyuki wrote:
> On Sun, 02 Nov 2008 00:18:37 +0530
> Balbir Singh <balbir@...ux.vnet.ibm.com> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/