Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752565AbYCQPRa (ORCPT ); Mon, 17 Mar 2008 11:17:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751445AbYCQPRW (ORCPT ); Mon, 17 Mar 2008 11:17:22 -0400 Received: from e28smtp03.in.ibm.com ([59.145.155.3]:53322 "EHLO e28smtp03.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751339AbYCQPRW (ORCPT ); Mon, 17 Mar 2008 11:17:22 -0400 Message-ID: <47DE8B1E.4010501@linux.vnet.ibm.com> Date: Mon, 17 Mar 2008 20:45:42 +0530 From: Balbir Singh Reply-To: balbir@linux.vnet.ibm.com Organization: IBM User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Paul Menage CC: Li Zefan , linux-mm@kvack.org, Hugh Dickins , Sudhir Kumar , YAMAMOTO Takashi , linux-kernel@vger.kernel.org, taka@valinux.co.jp, David Rientjes , Pavel Emelianov , Andrew Morton , KAMEZAWA Hiroyuki Subject: Re: [RFC][0/3] Virtual address space control for cgroups References: <20080316172942.8812.56051.sendpatchset@localhost.localdomain> <6599ad830803161626q1fcf261bta52933bb5e7a6bdd@mail.gmail.com> <47DDCDA7.4020108@cn.fujitsu.com> <6599ad830803161857r6d01f962vfd0f570e6124ab24@mail.gmail.com> <47DDFCEA.3030207@linux.vnet.ibm.com> <6599ad830803162222t6c32f5a1qd4d0af4887dfa910@mail.gmail.com> In-Reply-To: <6599ad830803162222t6c32f5a1qd4d0af4887dfa910@mail.gmail.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 Content-Length: 1332 Lines: 36 Paul Menage wrote: > On Mon, Mar 17, 2008 at 1:08 PM, Balbir Singh wrote: >> I understand the per-mm pointer overhead back to the cgroup. I don't understand >> the part about adding a per-mm pointer back to the "owning" task. We already >> have task->mm. > > Yes, but we don't have mm->owner, which is what I was proposing - > mm->owner would be a pointer typically to the mm's thread group > leader. It would remove the need to have to have pointers for the > various different cgroup subsystems that need to act on an mm rather > than a task_struct, since then you could use > mm->owner->cgroups[subsys_id]. > Aaahh.. Yes.. mm->owner might be a good idea. The only thing we'll need to handle is when mm->owner dies (I think the thread group is still kept around). The other disadvantage is the double dereferencing, which should not be all that bad. > But this is kind of orthogonal to whether virtual address space limits > should be a separate cgroup subsystem. > Yes, sure. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL -- 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/