On Mon, Feb 21, 2005 at 02:42:16AM -0600, Ray Bryant wrote:

All,

Just an update on the idea of migrating a process without suspending
it.

The hard part of the problem here is to make sure that the page_migrate()
system call sees all of the pages to migrate.  If the process that is
being migrated can still allocate pages, then the page_migrate() call
may miss some of the pages.

I would do an easy 95% solution:

When process has default process policy set temporarily a prefered policy
with the new node

[this won't work with multiple nodes though, so you have to decide on one
or stop the process if that is unacceptable] 

One way to solve this problem is to force the process to start allocating
pages on the new nodes before calling page_migrate().  There are a couple
of subcases:

(1)  For memory mapped files with a non-DEFAULT associated memory policy,
     one can use mbind() to fixup the memory policy.  (This assumes the
     Steve Longerbeam patches are applied, as I understand things).

I would just ignore them.  If user space wants it can handle it,
but it's probably not worth it.

(1) could be handled as part of the page_migrate() system call --
make one pass through the address space searching for mempolicy()
data structures, and updating them as necessary.  Then make a second
pass through and do the migrations.  Any new allocations will then
be done under the new mempolicy, so they won't be missed.  But this
still gets us into trouble if the old and new node lists are not
disjoint.

I wouldn't bother fixing up VMA policies. 

This doesn't handle anonymous memory or mapped files associated with
the DEFAULT policy.  A way around that would be to add a target cpu_id

[...]

I would set temporarily a prefered policy as mentioned above.

That only handles a single node, but you solution is not better.

-Andi
--
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:"aart@kvack.org"> aart@kvack.org </a>