Allow migration of mlocked pages

Allow migration of mlocked pages

[Christoph Lameter]

Hugh clarified the role of VM_LOCKED. So we can now implement
page migration for mlocked pages.

Allow the migration of mlocked pages. This means that try_to_unmap
must unmap mlocked pages in the migration case.

Signed-off-by: Christoph Lameter <clameter@sgi.com>

Index: linux-2.6.17-rc4-mm3/mm/rmap.c
===================================================================
--- linux-2.6.17-rc4-mm3.orig/mm/rmap.c	2006-05-23 15:10:22.484505490 -0700
+++ linux-2.6.17-rc4-mm3/mm/rmap.c	2006-05-23 18:13:25.532178041 -0700
@@ -626,9 +626,8 @@ static int try_to_unmap_one(struct page 
 	 * If it's recently referenced (perhaps page_referenced
 	 * skipped over this mm) then we should reactivate it.
 	 */
-	if ((vma->vm_flags & VM_LOCKED) ||
-			(ptep_clear_flush_young(vma, address, pte)
-				&& !migration)) {
+	if (!migration && ((vma->vm_flags & VM_LOCKED) ||
+			(ptep_clear_flush_young(vma, address, pte)))) {
 		ret = SWAP_FAIL;
 		goto out_unmap;
 	}
@@ -835,7 +834,7 @@ static int try_to_unmap_file(struct page
 
 	list_for_each_entry(vma, &mapping->i_mmap_nonlinear,
 						shared.vm_set.list) {
-		if (vma->vm_flags & VM_LOCKED)
+		if ((vma->vm_flags & VM_LOCKED) && !migration)
 			continue;
 		cursor = (unsigned long) vma->vm_private_data;
 		if (cursor > max_nl_cursor)
@@ -869,7 +868,7 @@ static int try_to_unmap_file(struct page
 	do {
 		list_for_each_entry(vma, &mapping->i_mmap_nonlinear,
 						shared.vm_set.list) {
-			if (vma->vm_flags & VM_LOCKED)
+			if ((vma->vm_flags & VM_LOCKED) && !migration)
 				continue;
 			cursor = (unsigned long) vma->vm_private_data;
 			while ( cursor < max_nl_cursor &&
Index: linux-2.6.17-rc4-mm3/mm/migrate.c
===================================================================
--- linux-2.6.17-rc4-mm3.orig/mm/migrate.c	2006-05-23 15:10:24.505864687 -0700
+++ linux-2.6.17-rc4-mm3/mm/migrate.c	2006-05-23 17:27:20.617652640 -0700
@@ -615,15 +615,13 @@ static int unmap_and_move(new_page_t get
 	/*
 	 * Establish migration ptes or remove ptes
 	 */
-	if (try_to_unmap(page, 1) != SWAP_FAIL) {
-		if (!page_mapped(page))
-			rc = move_to_new_page(newpage, page);
-	} else
-		/* A vma has VM_LOCKED set -> permanent failure */
-		rc = -EPERM;
+	try_to_unmap(page, 1);
+	if (!page_mapped(page))
+		rc = move_to_new_page(newpage, page);
 
 	if (rc)
 		remove_migration_ptes(page, page);
+
 unlock:
 	unlock_page(page);
 

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

Re: Allow migration of mlocked pages

[Hugh Dickins]

On Tue, 23 May 2006, Christoph Lameter wrote:

> Hugh clarified the role of VM_LOCKED. So we can now implement
> page migration for mlocked pages.
> 
> Allow the migration of mlocked pages. This means that try_to_unmap
> must unmap mlocked pages in the migration case.
> 
> Signed-off-by: Christoph Lameter <clameter@sgi.com>

Acked-by: Hugh Dickins <hugh@veritas.com>

But it does need to sit in -mm for a while; though just sitting
there isn't going to get much testing done - any ideas on how
we could expose migration of VM_LOCKED pages to wider testing?

Hugh

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

Re: Allow migration of mlocked pages

[Christoph Lameter]

On Wed, 24 May 2006, Hugh Dickins wrote:

> But it does need to sit in -mm for a while; though just sitting
> there isn't going to get much testing done - any ideas on how
> we could expose migration of VM_LOCKED pages to wider testing?

I ran a test program that mlocked an array of pages and then migrated it
via sys_move_pages() and then verified what happened. Will run some more 
stress tests today.

ldso and glibc create some mlocked pages for each binary. If we do 
migration with MPOL_MF_MOVE_ALL (common way of migrating pages) then 
we usually will have to migrate VM_LOCKED pages of ldso and glibc. So 
almost any testng of page migration will invariably involve migration of 
VM_LOCKED pages.


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

Re: Allow migration of mlocked pages

[Hugh Dickins]

On Wed, 24 May 2006, Christoph Lameter wrote:
> 
> I ran a test program that mlocked an array of pages and then migrated it
> via sys_move_pages() and then verified what happened. Will run some more 
> stress tests today.
> 
> ldso and glibc create some mlocked pages for each binary. If we do 
> migration with MPOL_MF_MOVE_ALL (common way of migrating pages) then 
> we usually will have to migrate VM_LOCKED pages of ldso and glibc. So 
> almost any testng of page migration will invariably involve migration of 
> VM_LOCKED pages.

Oh, I'm not worried about whether ordinary VM_LOCKED pages will get
migrated properly, I can't see any problem with that.  It's whether
something somewhere is using mlock and somehow relying on the
physical pages to be pinned.  I don't know what form that "somehow"
would take, and I'm not saying there is or can be any such thing:
just worried that we want wide exposure yet few testers migrate.

Hugh

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

Re: Allow migration of mlocked pages

[Christoph Lameter]

On Wed, 24 May 2006, Hugh Dickins wrote:

> Oh, I'm not worried about whether ordinary VM_LOCKED pages will get
> migrated properly, I can't see any problem with that.  It's whether
> something somewhere is using mlock and somehow relying on the
> physical pages to be pinned.  I don't know what form that "somehow"
> would take, and I'm not saying there is or can be any such thing:
> just worried that we want wide exposure yet few testers migrate.

All of these driver mappings are installed using remap_pfn_page. These are 
mappings that are not considered by page migration at all because:

1. They are marked VM_PFNMAP and VM_IO. vma_migratable() checks for those.
   vmas so marked will not be scanned for pages to migrate.

2. No page struct exists. check_pte_range and do_move_pages
   will skip these entries. There will never be an attempt
   to migrate.

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

Re: Allow migration of mlocked pages

[Hugh Dickins]

On Wed, 24 May 2006, Christoph Lameter wrote:
> On Wed, 24 May 2006, Hugh Dickins wrote:
> 
> > Oh, I'm not worried about whether ordinary VM_LOCKED pages will get
> > migrated properly, I can't see any problem with that.  It's whether
> > something somewhere is using mlock and somehow relying on the
> > physical pages to be pinned.  I don't know what form that "somehow"
> > would take, and I'm not saying there is or can be any such thing:
> > just worried that we want wide exposure yet few testers migrate.
> 
> All of these driver mappings are installed using remap_pfn_page. These are 
> mappings that are not considered by page migration at all because:

Misunderstanding again.  I've no worries about those drivers
you've supplied a patch for, what you've done there is surely okay.

I'm (slightly) worried there's some app out there that's been using
mlock to pin physical pages.  My worry may be senseless: how can
physical pages mean anything to it without a driver in the kernel
to cooperate in the assumption?

If it were a big worry, I wouldn't have sent you in this
"migrate VM_LOCKED" direction at all.  I'm all for it, just
cautioning that we want a period of exposure to varied testing.

Hugh

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