linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Simon.Derr@bull.net, clameter@sgi.com, akpm@osdl.org,
	kravetz@us.ibm.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, magnus.damm@gmail.com,
	marcelo.tosatti@cyclades.com
Subject: Re: [PATCH 4/4] Swap migration V3: sys_migrate_pages interface
Date: Fri, 21 Oct 2005 08:15:53 -0700	[thread overview]
Message-ID: <20051021081553.50716b97.pj@sgi.com> (raw)
In-Reply-To: <435896CA.1000101@jp.fujitsu.com>

Kame wrote:
>> How about this ?
>> +cpuset_update_task_mems_allowed(task, new);    (this isn't implemented now

One task cannot directly update anothers mems_allowed.  The locking on
a task's mems_allowed only allows modifying it in the context of its
current task.  This avoids taking a lock to read out the (possibly
multiple word) mems_allowed value when checking it in __alloc_pages().

Grep in kernel/cpuset.c for "mems_generation" to see the mechanism
used to insure that the task mems_allowed is updated, before any
allocation of memory, to match its cpuset.

> *new* is already guaranteed to be the subset of current mem_allowed.
> Is this violate the permission ?

I think that sys_migrate_pages() allows one task to migrate the
pages of another.

 * If task A is going to migrate task B's memory, then it should do
   so within task B's cpuset constraints (or as close as it can, in
   the case of say avoiding ECC soft errors, where the task context
   of the affected pages is not easily available).  If A doesn't like
   B's cpuset constraints, then A should change them first, using the
   appropriate cpuset API's, if A has permission to do so.  In the
   ECC soft correction case, just move the page the nearest place
   one can find free memory - from what I can tell ensuring that cpuset
   constraints are honored is too expensive (walking the task list for
   each page to find which task references that mm struct.)

   So this check ensures that A is not moving B's memory outside of
   the nodes in B's cpuset.

 * Christoph - what is the permissions check on sys_migrate_pages()?
   It would seem inappropriate for 'guest' to be able to move the
   memory of 'root'.

> Simon Derr wrote:
> > Automatically updating the ->mems_allowed field as you suggest would 
> > require that the kernel do the same checks in sys_migrage_pages(). Sounds 
> > not as a very good idea to me.

If I am understanding this correctly, this sys_migrate_pages() call
seems most useful in the situation that the pages are being moved
within the nodes already allowed to the target task (perhaps because
the kernel is configured w/o cpusets).  Otherwise, you should first
change the mems_allowed of the target task to allow these nodes, and in
that case, you can just use the new cpuset 'memory_migrate' flag (in a
patch in my outgoing queue, that I need to send real soon now) to ask
that existing pages be migrated when that cpuset moves, and when tasks
are moved into that cpuset.

I agree with Simon that sys_migrate_pages() does not want to get in
the business of replicating the checks on updating mems_allowed that
are in the cpuset code.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

--
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>

  parent reply	other threads:[~2005-10-21 15:15 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-20 22:59 [PATCH 0/4] Swap migration V3: Overview Christoph Lameter
2005-10-20 22:59 ` [PATCH 1/4] Swap migration V3: LRU operations Christoph Lameter
2005-10-21  6:06   ` Dave Hansen
2005-10-21  6:27     ` Magnus Damm
2005-10-21  6:56       ` Dave Hansen
2005-10-21  7:25         ` Magnus Damm
2005-10-21 15:42         ` Christoph Lameter
2005-10-21 11:49     ` Nikita Danilov
2005-10-20 22:59 ` [PATCH 2/4] Swap migration V3: Page Eviction Christoph Lameter
2005-10-22  1:06   ` Marcelo Tosatti
2005-10-20 22:59 ` [PATCH 3/4] Swap migration V3: MPOL_MF_MOVE interface Christoph Lameter
2005-10-20 22:59 ` [PATCH 4/4] Swap migration V3: sys_migrate_pages interface Christoph Lameter
2005-10-21  2:55   ` KAMEZAWA Hiroyuki
2005-10-21  7:07     ` Simon Derr
2005-10-21  7:20       ` KAMEZAWA Hiroyuki
2005-10-21  7:39         ` Simon Derr
2005-10-21  7:46           ` KAMEZAWA Hiroyuki
2005-10-21 15:22           ` Paul Jackson
2005-10-21 15:15         ` Paul Jackson [this message]
2005-10-21 15:21           ` Kamezawa Hiroyuki
2005-10-21 18:10             ` Paul Jackson
2005-10-21 18:26               ` Christoph Lameter
2005-10-21 18:57                 ` Paul Jackson
2005-10-21 15:47           ` Christoph Lameter
2005-10-21 16:18             ` Ray Bryant
2005-10-21 16:33               ` Christoph Lameter
2005-10-21 15:18         ` Paul Jackson
2005-10-21 16:27         ` Christoph Lameter
2005-10-21 16:59           ` Kamezawa Hiroyuki
2005-10-21 17:03           ` Paul Jackson
2005-10-21 17:06             ` Christoph Lameter
2005-10-21 18:17               ` Paul Jackson
2005-10-20 23:06 ` [PATCH 0/4] Swap migration V3: Overview Andrew Morton
2005-10-20 23:46   ` mike kravetz
2005-10-21  3:22     ` KAMEZAWA Hiroyuki
2005-10-21  3:32       ` mike kravetz
2005-10-21  3:56         ` KAMEZAWA Hiroyuki
2005-10-21  4:22           ` mike kravetz
2005-10-21  5:13             ` KAMEZAWA Hiroyuki
2005-10-21 15:28     ` Paul Jackson
2005-10-21 16:00       ` mike kravetz
2005-10-21  5:59   ` KAMEZAWA Hiroyuki
2005-10-22  1:16     ` Marcelo Tosatti
2005-10-21 15:54   ` Christoph Lameter
2005-10-21  1:57 ` Magnus Damm
2005-10-22  0:50   ` Marcelo Tosatti
2005-10-23 12:50     ` Magnus Damm
2005-10-24  7:44       ` Marcelo Tosatti
2005-10-25 11:37         ` Magnus Damm
2005-10-25 14:37           ` Marcelo Tosatti
2005-10-26  7:04             ` Magnus Damm
2005-10-27 15:01               ` Marcelo Tosatti
2005-10-27 20:43                 ` Andrew Morton
2005-10-27 21:35                   ` Marcelo Tosatti
2005-10-28  3:07                     ` Andrew Morton

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=20051021081553.50716b97.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=Simon.Derr@bull.net \
    --cc=akpm@osdl.org \
    --cc=clameter@sgi.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kravetz@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=magnus.damm@gmail.com \
    --cc=marcelo.tosatti@cyclades.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox