LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Paul Menage" <menage@google.com>
To: "YAMAMOTO Takashi" <yamamoto@valinux.co.jp>
Cc: balbir@linux.vnet.ibm.com, akpm@linux-foundation.org,
	npiggin@suse.de, a.p.zijlstra@chello.nl,
	dhaval@linux.vnet.ibm.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, ebiederm@xmission.com,
	containers@lists.osdl.org, xemul@openvz.org
Subject: Re: [-mm PATCH 5/10] Memory controller task migration (v7)
Date: Tue, 28 Aug 2007 13:04:34 -0700	[thread overview]
Message-ID: <6599ad830708281304m18a34ab5m96692eafc55e3c57@mail.gmail.com> (raw)
In-Reply-To: <20070828083252.C7D5C1BFA2F@siro.lan>

On 8/28/07, YAMAMOTO Takashi <yamamoto@valinux.co.jp> wrote:
>
> although i have no good idea right now, something which allows
> to move a process with its thread group leader dead would be better.
>

One way I was thinking of approaching this problem was slightly different:

- every mm always has an "owning" task. Initially that will be the
thread that creates the mm

- if the owning thread exits or execs and *isn't* the last user of the
mm, then we may need to find a new owner for the mm:

1) My guess is that typically the thread that created the mm will also
be the last user of the mm - if this is the case, then in the normal
case we don't need to find a new owner.

2) If we do need a new owner, first look amongst the other threads in
the process (cheap, should find another user of the mm quickly)

3) next look in the child and parent threads (more expensive, but rarer)

4) if necessary, scan the entire thread list (expensive, but should
never be needed in general use)

The advantage of this is that we don't then need to have a memory
container pointer in the mm - we can just use the memory container of
the mm's owner.

With just a single container type needing to be tied to an mm, this
isn't a huge advantage since we're just replacing one pointer (memory
container) with another (owning task) and have similar levels of
complexity for both. But if we have multiple container subsystems that
need to be tied to a particular mm then they can both use the mm owner
pointer.

E.g. I want to add a swap container subsystem that restricts which
swap devices a group of processes can swap to, and how many pages they
can put into swap. And I want to be able to run this independently of
the in-memory page accounting subsystem. Having a task owner pointer
in the mm allows these to be indpendent subsystems, and (I believe)
isn't any more complex than the work involved to support moving an mm
whose thread group leader has exited or execd.

Paul

  reply	other threads:[~2007-08-28 20:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-24 15:19 [-mm PATCH 0/10] Memory controller introduction (v7) Balbir Singh
2007-08-24 15:19 ` [-mm PATCH 1/10] Memory controller resource counters (v7) Balbir Singh
2007-08-24 15:20 ` [-mm PATCH 2/10] Memory controller containers setup (v7) Balbir Singh
2007-08-24 15:20 ` [-mm PATCH 3/10] Memory controller accounting " Balbir Singh
2007-08-24 15:20 ` [-mm PATCH 4/10] Memory controller memory accounting (v7) Balbir Singh
2007-08-24 15:20 ` [-mm PATCH 5/10] Memory controller task migration (v7) Balbir Singh
2007-08-27  8:26   ` YAMAMOTO Takashi
2007-08-27 10:39     ` Balbir Singh
2007-08-28  8:32       ` YAMAMOTO Takashi
2007-08-28 20:04         ` Paul Menage [this message]
2007-08-24 15:20 ` [-mm PATCH 6/10] Memory controller add per container LRU and reclaim (v7) Balbir Singh
2007-08-24 15:21 ` [-mm PATCH 7/10] Memory controller OOM handling (v7) Balbir Singh
2007-08-24 15:21 ` [-mm PATCH 8/10] Memory controller add switch to control what type of pages to limit (v7) Balbir Singh
2007-08-24 15:21 ` [-mm PATCH 9/10] Memory controller make page_referenced() container aware (v7) Balbir Singh
2007-08-24 15:21 ` [-mm PATCH 10/10] Memory controller add documentation 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=6599ad830708281304m18a34ab5m96692eafc55e3c57@mail.gmail.com \
    --to=menage@google.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=containers@lists.osdl.org \
    --cc=dhaval@linux.vnet.ibm.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=npiggin@suse.de \
    --cc=xemul@openvz.org \
    --cc=yamamoto@valinux.co.jp \
    --subject='Re: [-mm PATCH 5/10] Memory controller task migration (v7)' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).