From: Ray Bryant <raybry@sgi.com>
To: linux-mm <linux-mm@kvack.org>
Cc: Paul Jackson <pj@sgi.com>, Robin Holt <holt@sgi.com>,
Andi Kleen <ak@muc.de>, Dave Hansen <haveblue@us.ibm.com>,
Marcello Tosatti <marcello@cyclades.com>,
Steve Longerbeam <stevel@mwwireless.net>,
Peter Chubb <peterc@gelato.unsw.edu.au>
Subject: manual page migration -- issue list
Date: Tue, 15 Feb 2005 17:52:05 -0600 [thread overview]
Message-ID: <42128B25.9030206@sgi.com> (raw)
I've been asked to repost this to the list with cc:'s to the interested
parties. The content below is the same as before, its the email headers
that are more interesting. :-) (I hope I didn't miss anyone.)
==============================REPOSTING================================
The following is an attempt to summarize the issues that have
been raised thus far in this discussion. I'm hoping that this
list can help us resolve the issues in a (somewhat) organized
manner:
(1) Should there be a new API or should/can the migration functionality
be folded under the NUMA API?
(2) If we decide to make a new API, then what parameters should
that system call take? Proposals have been made for all of
the following:
-- pid, va_start, va_end, count, old_nodes, new_nodes
-- pid, va_start, va_end, old_node_mask, new_node_mask
-- pid, va_start, va_end, old_node, new_node
-- same variations as above without the va_start/end arguments
(2) If we make a new API, how does that new API interact with the
NUMA API?
-- e. g.what happens when we migrate a VMA that has a mempolicy
associated with it?
(3) If we make a new API, how does this API interact with the rest
of the VM system. For example, when we migrate part of a VMA
do we split the VMA or not? (See also (4) below since if we
decide that the migration interface needs to be able to migrate
processes without stopping them, the whole concept of talking
about such ephemeral things as VMAs becomes pointless.)
(4) How general of a migration model are we supporting?
-- migration where old and new set of nodes might not be disjoint
-- migration of general processes (without suspension) or just
of suspended processes
-- how general of a migration model is necessary to get sufficient
users (more than SGI, say) to increase the chances of getting
the facility merged into the kernel.
(5) How do we determine what vma's to migrate? (Subquestion: Is
this done by the kernel or in user space?)
-- original idea: reference counts in /proc/pid/maps
-- newer idea: exclusion lists either set by marking the
file in some special way or by an explicit list
-- if we mark files as non-migratable, where is this information
stored?
(6) How does the migration API (in whatever form it takes) interact
with cpusets?
So first off, is this the complete list of issues? Can anyone suggest
an issue that isn't covered here?
--
-----------------------------------------------
Ray Bryant
512-453-9679 (work) 512-507-7807 (cell)
raybry@sgi.com raybry@austin.rr.com
The box said: "Requires Windows 98 or better",
so I installed Linux.
-----------------------------------------------
--
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>
next reply other threads:[~2005-02-15 23:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-15 23:52 Ray Bryant [this message]
2005-02-16 0:09 ` manual page migration -- issue list Paul Jackson
2005-02-16 0:28 ` Ray Bryant
2005-02-16 0:51 ` Paul Jackson
2005-02-16 1:17 ` Paul Jackson
2005-02-16 2:01 ` Robin Holt
2005-02-16 4:04 ` Ray Bryant
2005-02-16 4:28 ` Paul Jackson
2005-02-16 4:24 ` Paul Jackson
2005-02-16 3:55 ` Ray Bryant
2005-02-16 1:56 ` Robin Holt
2005-02-16 4:22 ` Paul Jackson
2005-02-16 9:20 ` Robin Holt
2005-02-16 10:20 ` Paul Jackson
2005-02-16 11:30 ` Robin Holt
2005-02-16 15:45 ` Paul Jackson
2005-02-16 16:08 ` Robin Holt
2005-02-16 19:23 ` Paul Jackson
2005-02-16 19:56 ` Robin Holt
2005-02-16 23:08 ` Ray Bryant
2005-02-16 23:05 ` Ray Bryant
2005-02-17 0:28 ` Paul Jackson
2005-02-16 1:41 ` Paul Jackson
2005-02-16 3:56 ` Ray Bryant
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=42128B25.9030206@sgi.com \
--to=raybry@sgi.com \
--cc=ak@muc.de \
--cc=haveblue@us.ibm.com \
--cc=holt@sgi.com \
--cc=linux-mm@kvack.org \
--cc=marcello@cyclades.com \
--cc=peterc@gelato.unsw.edu.au \
--cc=pj@sgi.com \
--cc=stevel@mwwireless.net \
/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