From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752413AbYDCEFw (ORCPT ); Thu, 3 Apr 2008 00:05:52 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750757AbYDCEFn (ORCPT ); Thu, 3 Apr 2008 00:05:43 -0400 Received: from E23SMTP06.au.ibm.com ([202.81.18.175]:50715 "EHLO e23smtp06.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750752AbYDCEFm (ORCPT ); Thu, 3 Apr 2008 00:05:42 -0400 Message-ID: <47F4577E.5060905@linux.vnet.ibm.com> Date: Thu, 03 Apr 2008 09:35:18 +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: Pavel Emelianov , Hugh Dickins , Sudhir Kumar , YAMAMOTO Takashi , lizf@cn.fujitsu.com, linux-kernel@vger.kernel.org, taka@valinux.co.jp, linux-mm@kvack.org, David Rientjes , Andrew Morton , KAMEZAWA Hiroyuki Subject: Re: [RFC][-mm] Add an owner to the mm_struct (v4) References: <20080401124312.23664.64616.sendpatchset@localhost.localdomain> <47F3D62E.4070808@linux.vnet.ibm.com> <6599ad830804021253y6bf3b37y9bf1167b63c32e70@mail.gmail.com> In-Reply-To: <6599ad830804021253y6bf3b37y9bf1167b63c32e70@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 Paul Menage wrote: > On Wed, Apr 2, 2008 at 11:53 AM, Balbir Singh wrote: >> So far I've heard no objections or seen any review suggestions. Paul if you are >> OK with this patch, I'll ask Andrew to include it in -mm. > > My only thoughts were: > > - I think I'd still prefer CONFIG_MM_OWNER to be auto-selected rather > than manually configured, but it's not a huge deal either way. > It is auto-selected now by CONFIG_CGROUP_MEM_RES_CTLR in the latest patchset > - in theory I think we should goto retry if we get to the end of > mm_update_next_owner() without finding any other owner. Otherwise we > could miss another user if we race with one process forking a new > child and then exiting? > When we the current task is exiting and we've verified that we are mm->owner and we cannot miss the new process since through the process of forking, it would have added the new process to the tasklist before exiting. > - I was looking through the exit code trying to convince myself that > current is still on the tasklist until after it makes this call. If it > isn't then we could have trouble finding the new owner. But I can't > figure out for sure exactly at what point we come off the tasklist. > We come off the task list in __unhash_process(), which is in turn called by release_task() through __exit_signal(). > - I think we only need the cgroup callback in the event that > current->cgroups != new_owner->cgroups. (Hmm, have we already been > moved back to the root cgroup by this point? If so, then we'll have no > way to know which cgruop to unaccount from). > I checked to see that cgroup_exit is called after mm_update_new_owner(). We call mm_update_new_owner() from exit_mm(). I did not check for current->cgroups != new_owner->cgroups, since I did not want to limit the callbacks. An interested callback can make that check and no-op the callback. I am going to change the rcu_read_lock(), so that it is released after we take the task_lock() and repost the patch -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL