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