All of lore.kernel.org
 help / color / mirror / Atom feed
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Paul Menage <menage@google.com>
Cc: linux-mm@kvack.org, Hugh Dickins <hugh@veritas.com>,
	Sudhir Kumar <skumar@linux.vnet.ibm.com>,
	YAMAMOTO Takashi <yamamoto@valinux.co.jp>,
	lizf@cn.fujitsu.com, linux-kernel@vger.kernel.org,
	taka@valinux.co.jp, David Rientjes <rientjes@google.com>,
	Pavel Emelianov <xemul@openvz.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [RFC][-mm] Memory controller add mm->owner
Date: Wed, 26 Mar 2008 17:11:56 +0530	[thread overview]
Message-ID: <47EA3684.60107@linux.vnet.ibm.com> (raw)
In-Reply-To: <6599ad830803260420v236127cfydd8cf828fcce65bb@mail.gmail.com>

Paul Menage wrote:
> On Wed, Mar 26, 2008 at 3:29 AM, Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
>>  >>
>>  >> - in the worst case, it's not going to be worse than doing a
>>  >> for_each_thread() loop
>>  >>
>>
>>  This will have to be the common case, since you never know what combination of
>>  clone calls did CLONE_VM and what did CLONE_THREAD. At exit time, we need to pay
>>  a for_each_process() overhead.
> 
> I'm not convinced of this. All we have to do is find some other
> process p where p->mm == current->mm and make it the new owner.
> Exactly what sequence of clone() calls was used to cause the sharing
> isn't really relevant. I really think that a suitable candidate will
> be found amongst your children or your first sibling in 99.9% of those
> cases where more than one process is using an mm.
> 

Hmmm.. the 99.9% of the time is just guess work (not measured, could be possibly
true). I see and understand your code below. But before I try and implement
something like that, I was wondering why zap_threads() does not have that
heuristic. That should explain my inhibition.

Can anyone elaborate on zap_threads further?

-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL

WARNING: multiple messages have this Message-ID (diff)
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Paul Menage <menage@google.com>
Cc: linux-mm@kvack.org, Hugh Dickins <hugh@veritas.com>,
	Sudhir Kumar <skumar@linux.vnet.ibm.com>,
	YAMAMOTO Takashi <yamamoto@valinux.co.jp>,
	lizf@cn.fujitsu.com, linux-kernel@vger.kernel.org,
	taka@valinux.co.jp, David Rientjes <rientjes@google.com>,
	Pavel Emelianov <xemul@openvz.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [RFC][-mm] Memory controller add mm->owner
Date: Wed, 26 Mar 2008 17:11:56 +0530	[thread overview]
Message-ID: <47EA3684.60107@linux.vnet.ibm.com> (raw)
In-Reply-To: <6599ad830803260420v236127cfydd8cf828fcce65bb@mail.gmail.com>

Paul Menage wrote:
> On Wed, Mar 26, 2008 at 3:29 AM, Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
>>  >>
>>  >> - in the worst case, it's not going to be worse than doing a
>>  >> for_each_thread() loop
>>  >>
>>
>>  This will have to be the common case, since you never know what combination of
>>  clone calls did CLONE_VM and what did CLONE_THREAD. At exit time, we need to pay
>>  a for_each_process() overhead.
> 
> I'm not convinced of this. All we have to do is find some other
> process p where p->mm == current->mm and make it the new owner.
> Exactly what sequence of clone() calls was used to cause the sharing
> isn't really relevant. I really think that a suitable candidate will
> be found amongst your children or your first sibling in 99.9% of those
> cases where more than one process is using an mm.
> 

Hmmm.. the 99.9% of the time is just guess work (not measured, could be possibly
true). I see and understand your code below. But before I try and implement
something like that, I was wondering why zap_threads() does not have that
heuristic. That should explain my inhibition.

Can anyone elaborate on zap_threads further?

-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2008-03-26 11:45 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-24 14:01 [RFC][-mm] Memory controller add mm->owner Balbir Singh
2008-03-24 14:01 ` Balbir Singh
2008-03-24 15:03 ` Paul Menage
2008-03-24 15:03   ` Paul Menage
2008-03-24 16:21   ` Balbir Singh
2008-03-24 16:21     ` Balbir Singh
2008-03-24 16:34     ` Paul Menage
2008-03-24 16:34       ` Paul Menage
2008-03-24 17:33       ` Balbir Singh
2008-03-24 17:33         ` Balbir Singh
2008-03-24 17:46         ` Paul Menage
2008-03-24 17:46           ` Paul Menage
2008-03-25 11:41           ` Balbir Singh
2008-03-25 11:41             ` Balbir Singh
2008-03-26 10:29             ` Balbir Singh
2008-03-26 10:29               ` Balbir Singh
2008-03-26 11:20               ` Paul Menage
2008-03-26 11:20                 ` Paul Menage
2008-03-26 11:41                 ` Balbir Singh [this message]
2008-03-26 11:41                   ` Balbir Singh
2008-03-26 15:21                   ` Paul Menage
2008-03-26 15:21                     ` Paul Menage
2008-03-25  1:26 ` Li Zefan
2008-03-25  1:26   ` Li Zefan
2008-03-25 15:48   ` Balbir Singh
2008-03-25 15:48     ` Balbir Singh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47EA3684.60107@linux.vnet.ibm.com \
    --to=balbir@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=hugh@veritas.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=menage@google.com \
    --cc=rientjes@google.com \
    --cc=skumar@linux.vnet.ibm.com \
    --cc=taka@valinux.co.jp \
    --cc=xemul@openvz.org \
    --cc=yamamoto@valinux.co.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.