From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754151AbYKFHXg (ORCPT ); Thu, 6 Nov 2008 02:23:36 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752918AbYKFHX1 (ORCPT ); Thu, 6 Nov 2008 02:23:27 -0500 Received: from e28smtp02.in.ibm.com ([59.145.155.2]:41925 "EHLO e28smtp02.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752417AbYKFHX0 (ORCPT ); Thu, 6 Nov 2008 02:23:26 -0500 Message-ID: <49129644.8090805@linux.vnet.ibm.com> Date: Thu, 06 Nov 2008 12:31:24 +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: Paul Menage CC: KAMEZAWA Hiroyuki , linux-mm@kvack.org, YAMAMOTO Takashi , lizf@cn.fujitsu.com, linux-kernel@vger.kernel.org, Nick Piggin , David Rientjes , Pavel Emelianov , Dhaval Giani , Andrew Morton , Srivatsa Vaddagiri Subject: Re: [mm] [PATCH 4/4] Memory cgroup hierarchy feature selector References: <20081101184812.2575.68112.sendpatchset@balbir-laptop> <20081101184902.2575.11443.sendpatchset@balbir-laptop> <20081102143817.99edca6d.kamezawa.hiroyu@jp.fujitsu.com> <490D42C7.4000301@linux.vnet.ibm.com> <20081102152412.2af29a1b.kamezawa.hiroyu@jp.fujitsu.com> <490DCCC9.5000508@linux.vnet.ibm.com> <6599ad830811032237q14c065efx4316fee8f8daa515@mail.gmail.com> <49129601.4040008@linux.vnet.ibm.com> In-Reply-To: <49129601.4040008@linux.vnet.ibm.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 Balbir Singh wrote: > Paul Menage wrote: >> On Sun, Nov 2, 2008 at 7:52 AM, Balbir Singh wrote: >>> That should not be hard, but having it per-subtree sounds a little complex in >>> terms of exploiting from the end-user perspective and from symmetry perspective >>> (the CPU cgroup controller provides hierarchy control for the full hierarchy). >>> >> The difference is that the CPU controller works in terms of shares, >> whereas memory works in terms of absolute memory size. So it pretty >> much has to limit the hierarchy to a single tree. Also, I didn't think >> that you could modify the shares for the root cgroup - what would that >> mean if so? >> > > The shares are proportional for the CPU controller. I am confused as to which > shares (CPU you are talking about? > >> With this patch set as it is now, the root cgroup's lock becomes a >> global memory allocation/deallocation lock, which seems a bit painful. > > Yes, true, but then that is the cost associated with using a hierarchy. > >> Having a bunch of top-level cgroups each with their own independent >> memory limits, and allowing sub cgroups of them to be constrained by >> the parent's memory limit, seems more useful than a single hierarchy >> connected at the root. > > That is certainly do-able, but can be confusing to users, given how other > controllers work. We can document that > >> In what realistic circumstances do you actually want to limit the root >> cgroup's memory usage? >> > > Good point, I would expect that people would mostly use the hierarchy with > soft-limits or shares. I am now beginning to like Kamezawa and your suggestion > of limiting usage to subtrees. Oh! I am not sure if I mentioned, but you don't need to limit usage at the root. Any parent along the hierarchy can be limited and it will act as if the entire subtree is limited by that limit. -- Balbir