page migration

page migration

[Ray Bryant]

[-- Attachment #1: Type: text/plain, Size: 2811 bytes --]

Resending to some more familiar addresses....

-------- Original Message --------
Subject: Re: page migration
Date: Sun, 26 Dec 2004 16:37:37 -0600
From: Ray Bryant <raybry@sgi.com>
To: Dave Hansen <dave@sr71.net>
References: <41BDFBDC.8060007@sgi.com> <20041213213628.GC27473@logos.cnet>	 
<41C44DE5.7060000@sgi.com> <20041218161339.GA2825@logos.cnet>	 
<41CB11B6.2060303@sgi.com> <1103831159.6888.4.camel@localhost>

Dave,

The attached tar file contains a version of the mhp3 patch with the following
properties:

(1)  It splits out the memory migration patches into a separate series file.
(2)  The remaining patches are in the hotplug directory with its own
       series files.
(3)  Rollup patches for the two sets of patches are included.

If one applies the memory_migration patches first, the result compiles and
links but I admit I have not tested it.

If one then applies the memory_hotplug patch, the result applies cleanly and
if one then diff's the modified files (the ones that mhp3 changes) between the
two trees, that is in tree 1 we have my version of the memory migration
patches followed by my version of the hotplug patches, and in tree2 we have
mhp3 (plus a little patch to add the memory migration menu entries to the ia64
Kconfig file), the result is that the files are identical except for
mm/Makefile, where the line
for

obj-$(CONFIG_MEMORY_MIGRATE) += mmigrate.o

now appears earlier than it used to.

I've been unable to get (either) memory hotplug patch to compile.  It won't
compile for Altix at all, because Altix requires NUMA.  I tried it on a
Pentium machine, but apparently I didn't grab the correct config.

Anyway, the fact that the diff shows the split out patches are equivalent
to the full mhp3 patch should be good enough.

(The output of the comparison is included as the file reorder.diff).

I'd like to see this order of patches become the new order for the memory
hotplug patch.  That way, I won't have to pull the migration patches out
of the hotplug patch every time a new one comes out (I need the migration
code, but not the hotplug code for a project I am working on.)

Do you suppose this can be done???

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


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

[-- Attachment #2: mhp3_reordered.tgz --]
[-- Type: application/x-gzip, Size: 162360 bytes --]

Re: page migration

[Dave Hansen]

On Mon, 2005-01-03 at 11:48 -0600, Ray Bryant wrote:
> The attached tar file contains a version of the mhp3 patch with the following
> properties:
> 
> (1)  It splits out the memory migration patches into a separate series file.
> (2)  The remaining patches are in the hotplug directory with its own
>        series files.
> (3)  Rollup patches for the two sets of patches are included.
> 
> If one applies the memory_migration patches first, the result compiles and
> links but I admit I have not tested it.

Very cool, thanks for doing this.  

> I've been unable to get (either) memory hotplug patch to compile.  It won't
> compile for Altix at all, because Altix requires NUMA.  I tried it on a
> Pentium machine, but apparently I didn't grab the correct config.

Hmmm.  Did you check the configs here?

	http://sr71.net/patches/2.6.10/2.6.10-rc2-mm4-mhp3/configs/

> Anyway, the fact that the diff shows the split out patches are equivalent
> to the full mhp3 patch should be good enough.
> 
> (The output of the comparison is included as the file reorder.diff).

That's good to know.

> I'd like to see this order of patches become the new order for the memory
> hotplug patch.  That way, I won't have to pull the migration patches out
> of the hotplug patch every time a new one comes out (I need the migration
> code, but not the hotplug code for a project I am working on.)
> 
> Do you suppose this can be done???

Absolutely.  I was simply working them in the order that they were
implemented.  But, if we want the migration stuff merged first, I have
absolutely no problem with putting it first in the patch set.  

Next time I publish a tree, I'll see what I can do about producing
similar rollups to what you have, with migration broken out from
hotplug.

Thanks again for doing all of this work.

-- Dave

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

Re: page migration

[Ray Bryant]

Dave Hansen wrote:

> 
>>I'd like to see this order of patches become the new order for the memory
>>hotplug patch.  That way, I won't have to pull the migration patches out
>>of the hotplug patch every time a new one comes out (I need the migration
>>code, but not the hotplug code for a project I am working on.)
>>
>>Do you suppose this can be done???
> 
> 
> Absolutely.  I was simply working them in the order that they were
> implemented.  But, if we want the migration stuff merged first, I have
> absolutely no problem with putting it first in the patch set.  
> 
> Next time I publish a tree, I'll see what I can do about producing
> similar rollups to what you have, with migration broken out from
> hotplug.
> 

Cool.  Let me know if I can help at all with that.

Once we get that done I'd like to pursure getting the migration patches 
proposed for -mm and then mainline.  Does that make sense?

(perhaps it will make the hotplug patch easier to accept if we can get the 
memory migration stuff in first).

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

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

But the real question I am wrestling with at the moment is the following:

"Which approach to a NUMA process and memory migration facility would be more 
likely to get into the mainline kernel:

(1)  One based on the existing memory migration patches, or

(2)  something simpler just written for the NUMA process and memory
      migration case."

My preference would be to build on top of the existing code
from the hotplug project.  But the key goal here is to get the code
into the mainline.  I am a little concerned that the hotlug memory migration
code will be regarded as too complicated to get in, and I don't want that
to hold up the NUMA process and memory migration facility, which is what I am
working on and we (well, SGI) specifically need.

Suggestions?

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

Re: page migration\

[Marcelo Tosatti]

On Mon, Jan 03, 2005 at 01:04:35PM -0600, Ray Bryant wrote:
> Dave Hansen wrote:
> 
> >
> >>I'd like to see this order of patches become the new order for the memory
> >>hotplug patch.  That way, I won't have to pull the migration patches out
> >>of the hotplug patch every time a new one comes out (I need the migration
> >>code, but not the hotplug code for a project I am working on.)
> >>
> >>Do you suppose this can be done???
> >
> >
> >Absolutely.  I was simply working them in the order that they were
> >implemented.  But, if we want the migration stuff merged first, I have
> >absolutely no problem with putting it first in the patch set.  
> >
> >Next time I publish a tree, I'll see what I can do about producing
> >similar rollups to what you have, with migration broken out from
> >hotplug.
> >
> 
> Cool.  Let me know if I can help at all with that.
> 
> Once we get that done I'd like to pursure getting the migration patches 
> proposed for -mm and then mainline.  Does that make sense?
> 
> (perhaps it will make the hotplug patch easier to accept if we can get the 
> memory migration stuff in first).
> 
> 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.)
> 
> 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.)
> 
> But the real question I am wrestling with at the moment is the following:
> 
> "Which approach to a NUMA process and memory migration facility would be 
> more likely to get into the mainline kernel:
> 
> (1)  One based on the existing memory migration patches, or
> 
> (2)  something simpler just written for the NUMA process and memory
>      migration case."
> 
> My preference would be to build on top of the existing code
> from the hotplug project.  But the key goal here is to get the code
> into the mainline.  I am a little concerned that the hotlug memory migration
> code will be regarded as too complicated to get in, and I don't want that
> to hold up the NUMA process and memory migration facility, which is what I 
> am
> working on and we (well, SGI) specifically need.
> 
> Suggestions?

Hi Ray!

IMO, if you are in a hurry to get SGI's NUMA process/migration facility in mainline, we will 
have duplicated efforts/code in the future.

My suggestion is to wait for the memory migration code to get in. It might take sometime, yes, which
is a good thing from stabilization/maturity POV. If SGI has deadlines for the process/migration 
facility then implement your own (can even be based on the current migration infrastructure)
and do no try to merge it to the tree, please. 

This is also valid for the memory defragmentation effort I'm working on, I could have 
implemented standalone code myself (and I actually did), but it was a duplication,
to some extent, to what was already being done at the migration code.

So I had to try to change the migration code to attend my needs, and in the process 
me and Hirokazu came up with the migration cache, which is an advantage for every 
user of the memory migration.

Unification - you get the point.


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

Re: page migration\

[Marcelo Tosatti]

On Mon, Jan 03, 2005 at 02:24:06PM -0200, Marcelo Tosatti wrote:
> On Mon, Jan 03, 2005 at 01:04:35PM -0600, Ray Bryant wrote:
> > Dave Hansen wrote:
> > 
> > >
> > >>I'd like to see this order of patches become the new order for the memory
> > >>hotplug patch.  That way, I won't have to pull the migration patches out
> > >>of the hotplug patch every time a new one comes out (I need the migration
> > >>code, but not the hotplug code for a project I am working on.)
> > >>
> > >>Do you suppose this can be done???
> > >
> > >
> > >Absolutely.  I was simply working them in the order that they were
> > >implemented.  But, if we want the migration stuff merged first, I have
> > >absolutely no problem with putting it first in the patch set.  
> > >
> > >Next time I publish a tree, I'll see what I can do about producing
> > >similar rollups to what you have, with migration broken out from
> > >hotplug.
> > >
> > 
> > Cool.  Let me know if I can help at all with that.
> > 
> > Once we get that done I'd like to pursure getting the migration patches 
> > proposed for -mm and then mainline.  Does that make sense?
> > 
> > (perhaps it will make the hotplug patch easier to accept if we can get the 
> > memory migration stuff in first).
> > 
> > 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.)

Memory migration makes sense for defragmentation too.

I think we enough arguments for merging the migration code first, as you suggest.

Its also easier to merge part-by-part than everything in one bunch.

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

Re: page migration\

[Ray Bryant]

Marcelo Tosatti wrote:

> 
> 
> Memory migration makes sense for defragmentation too.
> 
> I think we enough arguments for merging the migration code first, as you suggest.
> 
> Its also easier to merge part-by-part than everything in one bunch.
> 
> Yes?

Absolutely.  I guess the only question is when to propose the merge with -mm
etc.  Is your defragmentation code in a good enough state to be proposed as
well, or should we wait a bit?

I think we need at least one user of the code before we can propose that the
memory migration code be merged, or do you think we the arguments are strong
enough we can proceed with users "pending"?

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

Re: page migration\

[Marcelo Tosatti]

On Mon, Jan 03, 2005 at 02:33:49PM -0600, Ray Bryant wrote:
> Marcelo Tosatti wrote:
> 
> >
> >
> >Memory migration makes sense for defragmentation too.
> >
> >I think we enough arguments for merging the migration code first, as you 
> >suggest.
> >
> >Its also easier to merge part-by-part than everything in one bunch.
> >
> >Yes?
> 
> Absolutely.  I guess the only question is when to propose the merge with -mm
> etc.  Is your defragmentation code in a good enough state to be proposed as
> well, or should we wait a bit?

No, we have to wait - its not ready yet.

But it is really simple and small, as soon as the "asynchronous" memory migration is working.

I'll try to work on it this weekend (I'm busy with other work unfortunately during the weekdays).

> I think we need at least one user of the code before we can propose that the
> memory migration code be merged, or do you think we the arguments are strong
> enough we can proceed with users "pending"?

IMO the arguments are strong enough that we can proceed with the current state.
I'm all for it.

Andrew knows the importance and the users of the memory migration infrastructure.

Dave, Hirokazu, what are your thoughts on this

Shall we CC Andrew?
--
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>

Re: page migration\

[Hirokazu Takahashi]

Hi,

> > Marcelo Tosatti wrote:
> > 
> > >Memory migration makes sense for defragmentation too.
> > >
> > >I think we enough arguments for merging the migration code first, as you 
> > >suggest.
> > >
> > >Its also easier to merge part-by-part than everything in one bunch.
> > >
> > >Yes?
> > 
> > Absolutely.  I guess the only question is when to propose the merge with -mm
> > etc.  Is your defragmentation code in a good enough state to be proposed as
> > well, or should we wait a bit?
> 
> No, we have to wait - its not ready yet.
> 
> But it is really simple and small, as soon as the "asynchronous" memory migration is working.
>
> > I think we need at least one user of the code before we can propose that the
> > memory migration code be merged, or do you think we the arguments are strong
> > enough we can proceed with users "pending"?
> 
> IMO the arguments are strong enough that we can proceed with the current state.
> I'm all for it.
> 
> Andrew knows the importance and the users of the memory migration infrastructure.
> 
> Dave, Hirokazu, what are your thoughts on this

Andrew is interested in our approach.
With Ray's help, it will proceed faster and become stable soon:)

> Shall we CC Andrew?
> 
--
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>

Re: page migration\

[Ray Bryant]

>>>
>>>Absolutely.  I guess the only question is when to propose the merge with -mm
>>>etc.  Is your defragmentation code in a good enough state to be proposed as
>>>well, or should we wait a bit?
>>
>>No, we have to wait - its not ready yet.
>>
>>But it is really simple and small, as soon as the "asynchronous" memory migration is working.
>>
>>
>>>I think we need at least one user of the code before we can propose that the
>>>memory migration code be merged, or do you think we the arguments are strong
>>>enough we can proceed with users "pending"?
>>
>>IMO the arguments are strong enough that we can proceed with the current state.
>>I'm all for it.
>>
>>Andrew knows the importance and the users of the memory migration infrastructure.
>>
>>Dave, Hirokazu, what are your thoughts on this
> 
> 
> Andrew is interested in our approach.
> With Ray's help, it will proceed faster and become stable soon:)
> 
> 
>>Shall we CC Andrew?
>>
> 
> 

If it is ok with everyone, I will email Andrew and see how he'd like to 
proceed on this, whether he'd prefer we contribute a solid "user" of the page 
migration code with a merged page migration patch, or if it would be ok to
submit the page migration code stand alone, given that there are multiple 
users "pending".

Of course, I come to this effort late in the game, and if anyone else would
prefer to do that instead, I will happily oblige them.

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

Re: page migration\

[Marcelo Tosatti]

On Tue, Jan 04, 2005 at 11:34:11AM -0600, Ray Bryant wrote:
> >>>
> >>>Absolutely.  I guess the only question is when to propose the merge with 
> >>>-mm
> >>>etc.  Is your defragmentation code in a good enough state to be proposed 
> >>>as
> >>>well, or should we wait a bit?
> >>
> >>No, we have to wait - its not ready yet.
> >>
> >>But it is really simple and small, as soon as the "asynchronous" memory 
> >>migration is working.
> >>
> >>
> >>>I think we need at least one user of the code before we can propose that 
> >>>the
> >>>memory migration code be merged, or do you think we the arguments are 
> >>>strong
> >>>enough we can proceed with users "pending"?
> >>
> >>IMO the arguments are strong enough that we can proceed with the current 
> >>state.
> >>I'm all for it.
> >>
> >>Andrew knows the importance and the users of the memory migration 
> >>infrastructure.
> >>
> >>Dave, Hirokazu, what are your thoughts on this
> >
> >
> >Andrew is interested in our approach.
> >With Ray's help, it will proceed faster and become stable soon:)
> >
> >
> >>Shall we CC Andrew?
> >>
> >
> >
> 
> If it is ok with everyone, I will email Andrew and see how he'd like to 
> proceed on this, whether he'd prefer we contribute a solid "user" of the 
> page migration code with a merged page migration patch, or if it would be 
> ok to
> submit the page migration code stand alone, given that there are multiple 
> users "pending".
> 
> Of course, I come to this effort late in the game, and if anyone else would
> prefer to do that instead, I will happily oblige them.

Please do that publically on linux-kernel - Dave has been doing most of the hardwork 
but I do not think he will mind if you start the discussion with Andrew.

Thanks Ray!
--
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>

Re: page migration

[Ray Bryant]

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

The attached patch changes "migrate_onepage(page)" to
"migrate_onepage(page, nodeid)".  For the case where
the caller doesn't care which target node is used,
then the call: "migrate_onepage(page, MIGRATE_NODE_ANY)"
causes migrate_onepage() to revert to its previous
behavior.

Since migrate_onepage() is only called in mmigrate.c
at the present time, this is a localized change.

This patch applies at the end of the migration
patches.

Unless there are objections, I'd like Dave to add this
patch to the hotplug patch as part of the page migration
patchset.

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

[-- Attachment #2: add-node-arg-to-migrate_onepage.patch --]
[-- Type: text/plain, Size: 2908 bytes --]

Index: linux-2.6.10-rc2-mm4-page-migration-only/include/linux/mmigrate.h
===================================================================
--- linux-2.6.10-rc2-mm4-page-migration-only.orig/include/linux/mmigrate.h	2004-12-23 17:04:41.000000000 -0800
+++ linux-2.6.10-rc2-mm4-page-migration-only/include/linux/mmigrate.h	2005-01-04 07:23:36.000000000 -0800
@@ -4,6 +4,7 @@
 #include <linux/config.h>
 #include <linux/mm.h>
 
+#define MIGRATE_NODE_ANY -1
 
 #ifdef CONFIG_MEMORY_MIGRATE
 extern int generic_migrate_page(struct page *, struct page *,
@@ -14,7 +15,7 @@ extern int migrate_page_buffer(struct pa
 					struct list_head *);
 extern int page_migratable(struct page *, struct page *, int,
 					struct list_head *);
-extern struct page * migrate_onepage(struct page *);
+extern struct page * migrate_onepage(struct page *, int nodeid);
 extern int try_to_migrate_pages(struct list_head *);
 
 #else
Index: linux-2.6.10-rc2-mm4-page-migration-only/mm/mmigrate.c
===================================================================
--- linux-2.6.10-rc2-mm4-page-migration-only.orig/mm/mmigrate.c	2005-01-04 07:09:24.000000000 -0800
+++ linux-2.6.10-rc2-mm4-page-migration-only/mm/mmigrate.c	2005-01-04 07:30:57.000000000 -0800
@@ -404,7 +404,7 @@ out_removing:
  * swapcache or anonymous memory.
  */
 struct page *
-migrate_onepage(struct page *page)
+migrate_onepage(struct page *page, int nodeid)
 {
 	struct page *newpage;
 	struct address_space *mapping;
@@ -434,7 +434,10 @@ migrate_onepage(struct page *page)
 	 * Allocate a new page with the same gfp_mask
 	 * as the target page has.
 	 */
-	newpage = page_cache_alloc(mapping, page->index);
+	if (nodeid == MIGRATE_NODE_ANY)
+		newpage = page_cache_alloc(mapping, page->index);
+	else
+		newpage = alloc_pages_node(nodeid, mapping->flags, 0);
 	if (newpage == NULL) {
 		unlock_page(page);
 		return ERR_PTR(-ENOMEM);
@@ -538,7 +541,7 @@ int try_to_migrate_pages(struct list_hea
 	list_for_each_entry_safe(page, page2, &pass1_list, lru) {
 		list_del(&page->lru);
 		if (PageLocked(page) || PageWriteback(page) ||
-		    IS_ERR(newpage = migrate_onepage(page))) {
+		    IS_ERR(newpage = migrate_onepage(page, MIGRATE_NODE_ANY))) {
 			if (page_count(page) == 1) {
 				/* the page is already unused */
 				putback_page_to_lru(page_zone(page), page);
@@ -556,7 +559,7 @@ int try_to_migrate_pages(struct list_hea
 	 */
 	list_for_each_entry_safe(page, page2, &pass2_list, lru) {
 		list_del(&page->lru);
-		if (IS_ERR(newpage = migrate_onepage(page))) {
+		if (IS_ERR(newpage = migrate_onepage(page, MIGRATE_NODE_ANY))) {
 			if (page_count(page) == 1) {
 				/* the page is already unused */
 				putback_page_to_lru(page_zone(page), page);
@@ -586,4 +589,4 @@ EXPORT_SYMBOL(generic_migrate_page);
 EXPORT_SYMBOL(migrate_page_common);
 EXPORT_SYMBOL(migrate_page_buffer);
 EXPORT_SYMBOL(page_migratable);
-
+EXPORT_SYMBOL(migrate_onepage);

Re: page migration

[Ray Bryant]

Marcelo Tosatti wrote:

> 
> 
> Hi Ray!
> 
> IMO, if you are in a hurry to get SGI's NUMA process/migration facility in mainline, we will 
> have duplicated efforts/code in the future.
> 
> My suggestion is to wait for the memory migration code to get in. It might take sometime, yes, which
> is a good thing from stabilization/maturity POV. If SGI has deadlines for the process/migration 
> facility then implement your own (can even be based on the current migration infrastructure)
> and do no try to merge it to the tree, please. 
> 

Unfortunately, I need my functionality merged into the mainline too.  Sigh.
(SGI wants all changes it needs in the mainline rather than as a separate
patch so as to minimize maintenance costs.  That makes perfect sense, but
then management ALSO wants us to meet schedules, which is much more difficult
to do if it depends on acceptance in mainline.)

See below....

> This is also valid for the memory defragmentation effort I'm working on, I could have 
> implemented standalone code myself (and I actually did), but it was a duplication,
> to some extent, to what was already being done at the migration code.
> 
> So I had to try to change the migration code to attend my needs, and in the process 
> me and Hirokazu came up with the migration cache, which is an advantage for every 
> user of the memory migration.
> 
> Unification - you get the point.
>

Definately.  I'd much prefer to work with the existing memory migration code.

So I'd propose doing the following:

(1)  I will work on getting my "NUMA memory migration" functionality
working on top of the existing memory migration code.
Once that is done, I'll work with y'all to get that plus the
memory migration code proposed for -mm and then the mainline.

(2)  Your memory defragmentation work would also be a user of the
memory migration code (perhaps even beating (1) into the tree).

I figure with two users of the memory migration code, plus the
memory hotplug patch coming along further down the road we stand
a better chance of getting the memory migration code merged into
the mainline.

Then if the memory migration code doesn't make it into mainline
early enough to meet the SGI schedules, well, then SGI will have
to figure out some way to deal with that.  (That's what management
is for, or so I've heard.  :-)  )

One question in this area is whether your migration cache code is
ready for integration with the rest of the memory migration patch?
(i. e. should I build on top of that too, or is that something
that could be added later, or perhaps it is not quite ready yet?)

> 
> 


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

Re: page migration

[Dave Hansen]

On Mon, 2005-01-03 at 13:04 -0600, Ray Bryant wrote:
> Once we get that done I'd like to pursure getting the migration patches 
> proposed for -mm and then mainline.  Does that make sense?

Yep.

> (perhaps it will make the hotplug patch easier to accept if we can get the 
> memory migration stuff in first).

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.  

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

> 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().  

> But the real question I am wrestling with at the moment is the following:
> 
> "Which approach to a NUMA process and memory migration facility would be more 
> likely to get into the mainline kernel:
> 
> (1)  One based on the existing memory migration patches, or
> 
> (2)  something simpler just written for the NUMA process and memory
>       migration case."
>
> My preference would be to build on top of the existing code
> from the hotplug project.  But the key goal here is to get the code
> into the mainline.  I am a little concerned that the hotlug memory migration
> code will be regarded as too complicated to get in, and I don't want that
> to hold up the NUMA process and memory migration facility, which is what I am
> working on and we (well, SGI) specifically need.

Are there any particular parts that you think are overly complicated?

Yes, it's complicated, but I'm not convinced that it can be implemented
much better than it has been.  This is another classic problem where 99%
of the work can be solved with 50% of the code.  It's getting it that
last 1% of the way and making it complete and *correct* that takes a lot
of work. 

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

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

Re: page migration

[Ray Bryant]

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>

Re: page migration

[William Lee Irwin III]

On Mon, Jan 03, 2005 at 02:15:23PM -0600, Ray Bryant wrote:
> 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.

Please don't limit the scope of page migration to that; cross-zone page
migration is needed to resolve pathologies arising in swapless systems.


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

Re: page migration

[Ray Bryant]

William Lee Irwin III wrote:

> 
> Please don't limit the scope of page migration to that; cross-zone page
> migration is needed to resolve pathologies arising in swapless systems.
> 
> 
> -- wli
>

I'm not proposing to simplify the memory migration code for what I need.
I'm just proposing to build what I need on top of the memory migration
code from the hotplug patch.  Support for cross-zone migration would
still be there, AFAIK.


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

Re: page migration

[Hirokazu Takahashi]

Hi Ray,

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

I also think we should rewrite page allocation in the memory migration
code, as the latest -mm tree includes NUMA aware page allocator. I guess
you should also care about mm/mempolicy.c and expand it for your purpose.
If memory migration is called after moving a process, a new page would
be allocated form a proper node automatically.

Have you checked mm/mempolicy.c?

Thanks,
Hirokazu Takahashi.
--
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>

Re: page migration

[Ray Bryant]

Hirokazu Takahashi wrote:

> 
> I also think we should rewrite page allocation in the memory migration
> code, as the latest -mm tree includes NUMA aware page allocator. I guess
> you should also care about mm/mempolicy.c and expand it for your purpose.
> If memory migration is called after moving a process, a new page would
> be allocated form a proper node automatically.
> 
> Have you checked mm/mempolicy.c?
> 
> Thanks,
> Hirokazu Takahashi.

My thinking on this was to update the mempolicy after page migration.
This works for my purposes since my plan is to

(1)  suspend the process via SIGSTOP
(2)  update the mempolicy
(3)  migrate the process's pages
(4)  migrate the process to the new cpu via set_schedaffinity()
(5)  resume the process via SIGCONT

These steps are to be performed via a user space program that implements
the actual migration function; the (2)-(4) are just the system calls that
implement this.  This keeps some of the function (i. e. which processes to
migrate) out of the kernel and allows the user some flexibility in what
order operations are performed as well as other functions that may go
along with this migration request.  (The actual function we are trying
to implement is to support >>job<< migration from one set of NUMA nodes to
another, and a job may consist of several processes.)

Given the order defined above, its not absolutely necessary to suspend
and resume the process (another reason for letting a user program coordinate
this) but that is part of the approach we are taking since this is being
initiated for scheduling reasons in a large NUMA system.

(2) is new function AFAIK; its on my TODO list.
-- 
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>

Re: process page migration

[Dave Hansen]

On Tue, 2005-01-04 at 11:30 -0600, Ray Bryant wrote:
> My thinking on this was to update the mempolicy after page migration.
> This works for my purposes since my plan is to
> 
> (1)  suspend the process via SIGSTOP
> (2)  update the mempolicy
> (3)  migrate the process's pages
> (4)  migrate the process to the new cpu via set_schedaffinity()
> (5)  resume the process via SIGCONT
> 
> These steps are to be performed via a user space program that implements
> the actual migration function; the (2)-(4) are just the system calls that
> implement this.  This keeps some of the function (i. e. which processes to
> migrate) out of the kernel and allows the user some flexibility in what
> order operations are performed as well as other functions that may go
> along with this migration request.  (The actual function we are trying
> to implement is to support >>job<< migration from one set of NUMA nodes to
> another, and a job may consist of several processes.)

We already have scheduler code which has some knowledge of when a
process is dragged from one node to another.  Combined with the per-node
RSS, could we make a decision about when a process needs to have
migration performed on its pages on a more automatic basis, without the
syscalls?

We could have a tunable for how aggressive this mechanism is, so that
the process wouldn't start running again on the more strict SGI machines
until a very large number of the pages are pulled over.  However, on
machines where process latency is more of an issue, the tunable could be
set to a much less aggressive value.

This would give normal, somewhat less exotic, NUMA machines the benefits
of page migration without the need for the process owner to do anything
manually to them, while also making sure that we keep the number of
interfaces to the migration code to a relative minimum.  

-- Dave

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

Re: process page migration

[Ray Bryant]

Dave Hansen wrote:
> On Tue, 2005-01-04 at 11:30 -0600, Ray Bryant wrote:
> 
>
> 
> 
> We already have scheduler code which has some knowledge of when a
> process is dragged from one node to another.  Combined with the per-node
> RSS, could we make a decision about when a process needs to have
> migration performed on its pages on a more automatic basis, without the
> syscalls?
> 

The only time I am proposing to do process and memory migration is in
response to requests issued from userspace.  This is not an automatic
process (see below for more details.)

> We could have a tunable for how aggressive this mechanism is, so that
> the process wouldn't start running again on the more strict SGI machines
> until a very large number of the pages are pulled over.  However, on
> machines where process latency is more of an issue, the tunable could be
> set to a much less aggressive value.
> 
> This would give normal, somewhat less exotic, NUMA machines the benefits
> of page migration without the need for the process owner to do anything
> manually to them, while also making sure that we keep the number of
> interfaces to the migration code to a relative minimum.  
> 
> -- Dave
> 
>

What I am working on is indeed manual process and page migration in a NUMA
system.  Specifically, we are running with cpusets, and the idea is to
support moving a job from one cpuset to another in response to batch scheduler
related decisions.  (The basic scenario is that a bunch of jobs are running,
each in its own cpuset, when a new high priority job arrives at the batch
scheduler.  The batch scheduler will pick some job to suspend, and start
the new job in that cpuset.  At some later point, one of the other jobs
finishes, and the scheduler now decides to move the suspended job to the
newly free cpuset.)  However, I don't want to tie the migration code I
am working on into cpusets, since the future of that is still uncertain.

Hence the migration system call I am proposing is something like:

     migrate_process_pages(pid, numnodes, old_node_list, new_node_list)

where the node lists are one dimensional arrays of size numnodes.
Pages on old_node_list[i] are moved to new_node_list[i].

(If cpusets exist on the underlying system, we will use the cpuset
infrastructure to tell us which pid's need to be moved.)

The only other new system call needed is something to update the memory
policy of the process to correspond to the new set of nodes.

Existing interfaces can be used to do the rest of the migration
functionality.

SGI's experience with automatically detecting when to pull pages from one
node to another based on program usage patterns has not been good.  IRIX
supported this kind of functionality, and all it ever seemed to do was to
move the wrong page at the wrong time (so I am told; it was before my time
with SGI...)

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

page migration patch

[Ray Bryant]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

Dave,

Attached is a trivial little patch that fixes the names on
the initial #ifdef and #define in linux/include/mmigrate.h
to match that file's name (it appears this was copied over from
some memory hotplug patch and was never updated....)

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

[-- Attachment #2: fix-include-name-in-mmigrate.h.patch --]
[-- Type: text/plain, Size: 755 bytes --]

Index: linux-2.6.10-rc2-mm4-page-migration-only/include/linux/mmigrate.h
===================================================================
--- linux-2.6.10-rc2-mm4-page-migration-only.orig/include/linux/mmigrate.h	2004-12-23 17:04:41.000000000 -0800
+++ linux-2.6.10-rc2-mm4-page-migration-only/include/linux/mmigrate.h	2005-01-07 08:33:40.000000000 -0800
@@ -1,5 +1,5 @@
-#ifndef _LINUX_MEMHOTPLUG_H
-#define _LINUX_MEMHOTPLUG_H
+#ifndef _LINUX_MMIGRATE_H
+#define _LINUX_MMIGRATE_H
 
 #include <linux/config.h>
 #include <linux/mm.h>
@@ -35,4 +35,4 @@ extern void arch_migrate_page(struct pag
 static inline void arch_migrate_page(struct page *page, struct page *newpage) {}
 #endif
 
-#endif /* _LINUX_MEMHOTPLUG_H */
+#endif /* _LINUX_MMIGRATE_H */

Re: page migration patch

[Dave Hansen]

On Fri, 2005-01-07 at 10:40 -0600, Ray Bryant wrote:
> Attached is a trivial little patch that fixes the names on
> the initial #ifdef and #define in linux/include/mmigrate.h
> to match that file's name (it appears this was copied over from
> some memory hotplug patch and was never updated....)

Looks obvious enough.  Thanks.

-- Dave

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

Re: migration cache, updated

[Ray Bryant]

[-- Attachment #1: Type: text/plain, Size: 1929 bytes --]

Marcello,

Attached is a patch which fixes some compiler warnings in mmigrate.c
that I was getting with the migration cache code.  The only substantive
change was to change:

         /* Wait for all operations against the page to finish. */
         ret = migrate_fn(page, newpage, &vlist);
         switch (ret) {
         default:
                 /* The page is busy. Try it later. */
                 goto out_busy;
         case -ENOENT:
                 /* The file the page belongs to has been truncated. */
                 page_cache_get(page);
                 page_cache_release(newpage);
                 newpage->mapping = NULL;
                 /* fall thru */
         case 0:
                 /* fall thru */
         }

in generic_migrate_page(), to:

         /* Wait for all operations against the page to finish. */
         ret = migrate_fn(page, newpage, &vlist);
         switch (ret) {
         case -ENOENT:
                 /* The file the page belongs to has been truncated. */
                 page_cache_get(page);
                 page_cache_release(newpage);
                 newpage->mapping = NULL;
                 /* fall thru */
         case 0:
                 break;
         default:
                 /* The page is busy. Try it later. */
                 goto out_busy;
         }

This change was made to get rid of the warning:

mm/mmigrate.c:500: warning: deprecated use of label at end of compound statement

I suppose you used the previous order to eliminate an extra branch or
some such.  Do you have any other suggestion on how to eliminate that
warning?
-- 
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.
-----------------------------------------------

[-- Attachment #2: fix-migration-cache-warnings.patch --]
[-- Type: text/plain, Size: 3087 bytes --]

Index: linux-2.6.10-rc2-mm4-page-migration-only/include/linux/swap.h
===================================================================
--- linux-2.6.10-rc2-mm4-page-migration-only.orig/include/linux/swap.h	2005-01-04 07:55:22.000000000 -0800
+++ linux-2.6.10-rc2-mm4-page-migration-only/include/linux/swap.h	2005-01-04 08:13:16.000000000 -0800
@@ -258,7 +258,7 @@ static inline int remove_exclusive_swap_
 {
 	return __remove_exclusive_swap_page(p, 0);
 }
-extern int migration_remove_entry(swp_entry_t);
+extern void migration_remove_entry(swp_entry_t);
 struct backing_dev_info;
 
 extern struct swap_list_t swap_list;
Index: linux-2.6.10-rc2-mm4-page-migration-only/mm/mmigrate.c
===================================================================
--- linux-2.6.10-rc2-mm4-page-migration-only.orig/mm/mmigrate.c	2005-01-04 07:55:22.000000000 -0800
+++ linux-2.6.10-rc2-mm4-page-migration-only/mm/mmigrate.c	2005-01-04 08:11:51.000000000 -0800
@@ -79,7 +79,6 @@ struct page *lookup_migration_cache(int 
 
 void migration_duplicate(swp_entry_t entry)
 {
-	int offset;
 	struct counter *cnt;
 
 	read_lock_irq(&migration_space.tree_lock);
@@ -96,32 +95,11 @@ void remove_from_migration_cache(struct 
         idr_remove(&migration_idr, id);
 	radix_tree_delete(&migration_space.page_tree, id);
 	ClearPageSwapCache(page);
-	page->private = NULL;
+	page->private = 0;
 	write_unlock_irq(&migration_space.tree_lock);
 }
 
-// FIXME: if the page is locked will it be correctly removed from migr cache?
-// check races
-
-int migration_remove_entry(swp_entry_t entry)
-{
-	struct page *page;
-	
-	page = find_get_page(&migration_space, entry.val);
-
-	if (!page)
-		BUG();
-
-	lock_page(page);	
-
-	migration_remove_reference(page, 1);
-
-	unlock_page(page);
-
-	page_cache_release(page);
-}
-
-int migration_remove_reference(struct page *page, int dec)
+void migration_remove_reference(struct page *page, int dec)
 {
 	struct counter *c;
 	swp_entry_t entry;
@@ -145,6 +123,28 @@ int migration_remove_reference(struct pa
 	}
 }
 
+
+// FIXME: if the page is locked will it be correctly removed from migr cache?
+// check races
+
+void migration_remove_entry(swp_entry_t entry)
+{
+	struct page *page;
+	
+	page = find_get_page(&migration_space, entry.val);
+
+	if (!page)
+		BUG();
+
+	lock_page(page);	
+
+	migration_remove_reference(page, 1);
+
+	unlock_page(page);
+
+	page_cache_release(page);
+}
+
 int detach_from_migration_cache(struct page *page)
 {
 	lock_page(page);	
@@ -486,9 +486,6 @@ generic_migrate_page(struct page *page, 
 	/* Wait for all operations against the page to finish. */
 	ret = migrate_fn(page, newpage, &vlist);
 	switch (ret) {
-	default:
-		/* The page is busy. Try it later. */
-		goto out_busy;
 	case -ENOENT:
 		/* The file the page belongs to has been truncated. */
 		page_cache_get(page);
@@ -496,7 +493,10 @@ generic_migrate_page(struct page *page, 
 		newpage->mapping = NULL;
 		/* fall thru */
 	case 0:
-		/* fall thru */
+		break;
+	default:
+		/* The page is busy. Try it later. */
+		goto out_busy;
 	}
 
 	arch_migrate_page(page, newpage);

Re: migration cache, updated

[Marcelo Tosatti]

On Fri, Jan 07, 2005 at 10:57:52AM -0600, Ray Bryant wrote:
> Marcello,
> 
> Attached is a patch which fixes some compiler warnings in mmigrate.c
> that I was getting with the migration cache code.  The only substantive
> change was to change:
> 
>         /* Wait for all operations against the page to finish. */
>         ret = migrate_fn(page, newpage, &vlist);
>         switch (ret) {
>         default:
>                 /* The page is busy. Try it later. */
>                 goto out_busy;
>         case -ENOENT:
>                 /* The file the page belongs to has been truncated. */
>                 page_cache_get(page);
>                 page_cache_release(newpage);
>                 newpage->mapping = NULL;
>                 /* fall thru */
>         case 0:
>                 /* fall thru */
>         }
> 
> in generic_migrate_page(), to:
> 
>         /* Wait for all operations against the page to finish. */
>         ret = migrate_fn(page, newpage, &vlist);
>         switch (ret) {
>         case -ENOENT:
>                 /* The file the page belongs to has been truncated. */
>                 page_cache_get(page);
>                 page_cache_release(newpage);
>                 newpage->mapping = NULL;
>                 /* fall thru */
>         case 0:
>                 break;
>         default:
>                 /* The page is busy. Try it later. */
>                 goto out_busy;
>         }
> 
> This change was made to get rid of the warning:
> 
> mm/mmigrate.c:500: warning: deprecated use of label at end of compound 
> statement
> 
> I suppose you used the previous order to eliminate an extra branch or
> some such.  Do you have any other suggestion on how to eliminate that
> warning?

Hi Ray,

No, I think your change is fine. I'll merge it to my tree (which currently
doesnt exist, yet).

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

> Index: linux-2.6.10-rc2-mm4-page-migration-only/include/linux/swap.h
> ===================================================================
> --- linux-2.6.10-rc2-mm4-page-migration-only.orig/include/linux/swap.h	2005-01-04 07:55:22.000000000 -0800
> +++ linux-2.6.10-rc2-mm4-page-migration-only/include/linux/swap.h	2005-01-04 08:13:16.000000000 -0800
> @@ -258,7 +258,7 @@ static inline int remove_exclusive_swap_
>  {
>  	return __remove_exclusive_swap_page(p, 0);
>  }
> -extern int migration_remove_entry(swp_entry_t);
> +extern void migration_remove_entry(swp_entry_t);
>  struct backing_dev_info;
>  
>  extern struct swap_list_t swap_list;
> Index: linux-2.6.10-rc2-mm4-page-migration-only/mm/mmigrate.c
> ===================================================================
> --- linux-2.6.10-rc2-mm4-page-migration-only.orig/mm/mmigrate.c	2005-01-04 07:55:22.000000000 -0800
> +++ linux-2.6.10-rc2-mm4-page-migration-only/mm/mmigrate.c	2005-01-04 08:11:51.000000000 -0800
> @@ -79,7 +79,6 @@ struct page *lookup_migration_cache(int 
>  
>  void migration_duplicate(swp_entry_t entry)
>  {
> -	int offset;
>  	struct counter *cnt;
>  
>  	read_lock_irq(&migration_space.tree_lock);
> @@ -96,32 +95,11 @@ void remove_from_migration_cache(struct 
>          idr_remove(&migration_idr, id);
>  	radix_tree_delete(&migration_space.page_tree, id);
>  	ClearPageSwapCache(page);
> -	page->private = NULL;
> +	page->private = 0;
>  	write_unlock_irq(&migration_space.tree_lock);
>  }
>  
> -// FIXME: if the page is locked will it be correctly removed from migr cache?
> -// check races
> -
> -int migration_remove_entry(swp_entry_t entry)
> -{
> -	struct page *page;
> -	
> -	page = find_get_page(&migration_space, entry.val);
> -
> -	if (!page)
> -		BUG();
> -
> -	lock_page(page);	
> -
> -	migration_remove_reference(page, 1);
> -
> -	unlock_page(page);
> -
> -	page_cache_release(page);
> -}
> -
> -int migration_remove_reference(struct page *page, int dec)
> +void migration_remove_reference(struct page *page, int dec)
>  {
>  	struct counter *c;
>  	swp_entry_t entry;
> @@ -145,6 +123,28 @@ int migration_remove_reference(struct pa
>  	}
>  }
>  
> +
> +// FIXME: if the page is locked will it be correctly removed from migr cache?
> +// check races
> +
> +void migration_remove_entry(swp_entry_t entry)
> +{
> +	struct page *page;
> +	
> +	page = find_get_page(&migration_space, entry.val);
> +
> +	if (!page)
> +		BUG();
> +
> +	lock_page(page);	
> +
> +	migration_remove_reference(page, 1);
> +
> +	unlock_page(page);
> +
> +	page_cache_release(page);
> +}
> +
>  int detach_from_migration_cache(struct page *page)
>  {
>  	lock_page(page);	
> @@ -486,9 +486,6 @@ generic_migrate_page(struct page *page, 
>  	/* Wait for all operations against the page to finish. */
>  	ret = migrate_fn(page, newpage, &vlist);
>  	switch (ret) {
> -	default:
> -		/* The page is busy. Try it later. */
> -		goto out_busy;
>  	case -ENOENT:
>  		/* The file the page belongs to has been truncated. */
>  		page_cache_get(page);
> @@ -496,7 +493,10 @@ generic_migrate_page(struct page *page, 
>  		newpage->mapping = NULL;
>  		/* fall thru */
>  	case 0:
> -		/* fall thru */
> +		break;
> +	default:
> +		/* The page is busy. Try it later. */
> +		goto out_busy;
>  	}
>  
>  	arch_migrate_page(page, newpage);

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

Re: page migration

[Yasunori Goto]

Hello Ray-san.

> > I've been unable to get (either) memory hotplug patch to compile.  It won't
> > compile for Altix at all, because Altix requires NUMA.  I tried it on a
> > Pentium machine, but apparently I didn't grab the correct config.
> 
> Hmmm.  Did you check the configs here?
> 
> 	http://sr71.net/patches/2.6.10/2.6.10-rc2-mm4-mhp3/configs/

CONFIG_NUMA with memory hotplug is disabled on -mhp3,
because some functions of memory hotplug are not defined yet and
some works like pgdat allocation are necessary.
.
I posted patches for them before holidays to LHMS.
http://sourceforge.net/mailarchive/forum.php?forum_id=223&max_rows=25&style=ultimate&viewmonth=200412

It is still for IA32. But, I would like to start works for IA64.
I guess it won't be duplication against your works.
But If you find something wrong, please let me know.

Bye.

-- 
Yasunori Goto <ygoto at us.fujitsu.com>


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

Re: page migration

[Ray Bryant]

Yasunori Goto wrote:
> Hello Ray-san.
> 
> 
>>>I've been unable to get (either) memory hotplug patch to compile.  It won't
>>>compile for Altix at all, because Altix requires NUMA.  I tried it on a
>>>Pentium machine, but apparently I didn't grab the correct config.
>>
>>Hmmm.  Did you check the configs here?
>>
>>	http://sr71.net/patches/2.6.10/2.6.10-rc2-mm4-mhp3/configs/
> 
> 
> CONFIG_NUMA with memory hotplug is disabled on -mhp3,
> because some functions of memory hotplug are not defined yet and
> some works like pgdat allocation are necessary.
> .
> I posted patches for them before holidays to LHMS.
> http://sourceforge.net/mailarchive/forum.php?forum_id=223&max_rows=25&style=ultimate&viewmonth=200412
> 
> It is still for IA32. But, I would like to start works for IA64.
> I guess it won't be duplication against your works.
> But If you find something wrong, please let me know.
> 
> Bye.
> 
Hello Goto-san,

Yes, as you surmise, I am mostly interested in the page migration
patches.  I was just trying to compile the hotplug patches to make
sure my "reordering" of the hotplug patchset (putting the page
migration patches first) didn't break hotplug.

I satisifed that goal by comparing the modified files after each
version of the hotplug patch (re-ordered versus original).  Since
the files turned out basically the same, that was good enough for
now.

I'm not sure why I couldn't get the hotplug patches to compile
on i386.  I used one of Dave Hansen's suggested configs.  Anyway
the comparison above was good enough for my purposes so I didn't
pursue this any further.

Of course, we also look forward to progress in the memory hotplug
area for ia64.

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