From: Ray Bryant <raybry@sgi.com>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: Hirokazu Takahashi <taka@valinux.co.jp>,
Marcello Tosatti <marcelo.tosatti@cyclades.com>,
linux-mm <linux-mm@kvack.org>
Subject: Re: page migration
Date: Mon, 03 Jan 2005 14:15:23 -0600 [thread overview]
Message-ID: <41D9A7DB.2020306@sgi.com> (raw)
In-Reply-To: <1104781061.25994.19.camel@localhost>
Dave Hansen wrote:
>
> I was going to do hotplug first only because it created a requirement
> for migration. Since you have a separate requirement for it, I have no
> objection to doing migration first.
>
Cool.
>
>>Of course, the "standalone" memory migration stuff makes most sense on NUMA,
>>and there is some minor interface changes there to support that (i. e. consider:
>>
>>migrate_onepage(page);
>>
>>vs
>>
>>migrate_onepage_node(page, node);
>>
>>what the latter does is to call alloc_pages_node() instead of
>>page_cache_alloc() to get the new page.)
>
>
> We might as well just change all of the users over to the NUMA version
> from the start. Having 2 different functions just causes confusion.
>
Yes, especially since alloc_pages_node() is defined regardless of whether
NUMA is defined (I've found out by some code inspection). So in the
non-DISCONTIGMEM cases, the node argument would just be ignored. I'll
put together a patch that moves the interface over to
migrate_onepage(page, node)
and fixes up the callers in the memory hotplug patches.
>
>>This is all to support NUMA process and memory migration, where the
>>required function is to move a process >>and<< its memory from one
>>set of nodes to another. (I should have a patch for these initial
>>interface changes later this week.)
>
>
> Well, moving the process itself isn't very hard, right? That's just a
> schedule().
>
Yes, that's the easy part. :-)
<snip>
>
>
> Anyway, I'd love to see a simpler version if it's possible. I'd just
> keep Marcello and Hirokazu in the loop if you're going to try.
>
> -- Dave
>
>
If the consensus is that the correct way to go is to propose the
memory migration patches as they are, then that is fine by me. I will
get my "NUMA process and memory migration" patch working on top of that
(so that we have a user) and then work with Andrew to get them into -mm
and then see what happens from there.
--
Best Regards,
Ray
-----------------------------------------------
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 prev parent reply other threads:[~2005-01-03 20:15 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-03 17:48 page migration Ray Bryant
2005-01-03 18:25 ` Dave Hansen
2005-01-03 19:04 ` Ray Bryant
2005-01-03 16:24 ` page migration\ Marcelo Tosatti
2005-01-03 17:13 ` Marcelo Tosatti
2005-01-03 20:33 ` Ray Bryant
2005-01-03 18:38 ` Marcelo Tosatti
2005-01-04 15:42 ` Hirokazu Takahashi
2005-01-04 17:34 ` Ray Bryant
2005-01-04 16:11 ` Marcelo Tosatti
2005-01-05 0:08 ` page migration Ray Bryant
2005-01-03 20:30 ` Ray Bryant
2005-01-03 19:37 ` Dave Hansen
2005-01-03 20:15 ` Ray Bryant [this message]
2005-01-03 20:17 ` William Lee Irwin III
2005-01-03 20:36 ` Ray Bryant
2005-01-04 14:42 ` Hirokazu Takahashi
2005-01-04 17:30 ` Ray Bryant
2005-01-04 17:40 ` process " Dave Hansen
2005-01-04 18:26 ` Ray Bryant
2005-01-07 16:40 ` page migration patch Ray Bryant
2005-01-10 2:58 ` Dave Hansen
2005-01-07 16:57 ` migration cache, updated Ray Bryant
2005-01-10 10:07 ` Marcelo Tosatti
2005-01-04 22:03 ` page migration Yasunori Goto
2005-01-04 23:58 ` 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=41D9A7DB.2020306@sgi.com \
--to=raybry@sgi.com \
--cc=haveblue@us.ibm.com \
--cc=linux-mm@kvack.org \
--cc=marcelo.tosatti@cyclades.com \
--cc=taka@valinux.co.jp \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.