From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754039AbYCQFXJ (ORCPT ); Mon, 17 Mar 2008 01:23:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751917AbYCQFW4 (ORCPT ); Mon, 17 Mar 2008 01:22:56 -0400 Received: from smtp-out.google.com ([216.239.45.13]:49685 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751376AbYCQFW4 (ORCPT ); Mon, 17 Mar 2008 01:22:56 -0400 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=IIskH/+/UgK7sjWt1Xeb69Zvt+fr2j9iGmhrowe5QOO1hsQscAoI980FSXovKi8SP pTYNfIS9QYlj5t/jl5Anw== Message-ID: <6599ad830803162222t6c32f5a1qd4d0af4887dfa910@mail.gmail.com> Date: Mon, 17 Mar 2008 13:22:48 +0800 From: "Paul Menage" To: balbir@linux.vnet.ibm.com Subject: Re: [RFC][0/3] Virtual address space control for cgroups 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" In-Reply-To: <47DDFCEA.3030207@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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]. But this is kind of orthogonal to whether virtual address space limits should be a separate cgroup subsystem. Paul