Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1332066 > unrolled thread

[PATCHv2 04/28] mm: make remove_migration_ptes() beyond mm/migration.c

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCHv2 04/28] mm: make remove_migration_ptes() beyond mm/migration.c "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-02-11 15:30 +0100
    Re: [PATCHv2 04/28] mm: make remove_migration_ptes() beyond  mm/migration.c Dave Hansen <dave.hansen@intel.com> - 2016-02-12 18:00 +0100
      Re: [PATCHv2 04/28] mm: make remove_migration_ptes() beyond  mm/migration.c "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-02-16 11:00 +0100
        Re: [PATCHv2 04/28] mm: make remove_migration_ptes() beyond  mm/migration.c Dave Hansen <dave.hansen@intel.com> - 2016-02-16 16:40 +0100

#1332066 — [PATCHv2 04/28] mm: make remove_migration_ptes() beyond mm/migration.c

The patch makes remove_migration_ptes() available to be used in
split_huge_page().

New parameter 'locked' added: as with try_to_umap() we need a way to
indicate that caller holds rmap lock.

We also shouldn't try to mlock() pte-mapped huge pages: pte-mapeed THP
pages are never mlocked.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 include/linux/rmap.h |  2 ++
 mm/migrate.c         | 15 +++++++++------
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 3d975e2252d4..49eb4f8ebac9 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -243,6 +243,8 @@ int page_mkclean(struct page *);
  */
 int try_to_munlock(struct page *);
 
+void remove_migration_ptes(struct page *old, struct page *new, bool locked);
+
 /*
  * Called by memory-failure.c to kill processes.
  */
diff --git a/mm/migrate.c b/mm/migrate.c
index 17db63b2dd36..993390dcf68d 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -172,7 +172,7 @@ static int remove_migration_pte(struct page *new, struct vm_area_struct *vma,
 	else
 		page_add_file_rmap(new);
 
-	if (vma->vm_flags & VM_LOCKED)
+	if (vma->vm_flags & VM_LOCKED && !PageCompound(new))
 		mlock_vma_page(new);
 
 	/* No need to invalidate - it was non-present before */
@@ -187,14 +187,17 @@ out:
  * Get rid of all migration entries and replace them by
  * references to the indicated page.
  */
-static void remove_migration_ptes(struct page *old, struct page *new)
+void remove_migration_ptes(struct page *old, struct page *new, bool locked)
 {
 	struct rmap_walk_control rwc = {
 		.rmap_one = remove_migration_pte,
 		.arg = old,
 	};
 
-	rmap_walk(new, &rwc);
+	if (locked)
+		rmap_walk_locked(new, &rwc);
+	else
+		rmap_walk(new, &rwc);
 }
 
 /*
@@ -706,7 +709,7 @@ static int writeout(struct address_space *mapping, struct page *page)
 	 * At this point we know that the migration attempt cannot
 	 * be successful.
 	 */
-	remove_migration_ptes(page, page);
+	remove_migration_ptes(page, page, false);
 
 	rc = mapping->a_ops->writepage(page, &wbc);
 
@@ -904,7 +907,7 @@ static int __unmap_and_move(struct page *page, struct page *newpage,
 
 	if (page_was_mapped)
 		remove_migration_ptes(page,
-			rc == MIGRATEPAGE_SUCCESS ? newpage : page);
+			rc == MIGRATEPAGE_SUCCESS ? newpage : page, false);
 
 out_unlock_both:
 	unlock_page(newpage);
@@ -1074,7 +1077,7 @@ static int unmap_and_move_huge_page(new_page_t get_new_page,
 
 	if (page_was_mapped)
 		remove_migration_ptes(hpage,
-			rc == MIGRATEPAGE_SUCCESS ? new_hpage : hpage);
+			rc == MIGRATEPAGE_SUCCESS ? new_hpage : hpage, false);
 
 	unlock_page(new_hpage);
 
-- 
2.7.0

[toc] | [next] | [standalone]

#1332905 — Re: [PATCHv2 04/28] mm: make remove_migration_ptes() beyond mm/migration.c

On 02/11/2016 06:21 AM, Kirill A. Shutemov wrote
> We also shouldn't try to mlock() pte-mapped huge pages: pte-mapeed THP
> pages are never mlocked.

That's kinda subtle.  Can you explain more?

If we did the following:

	ptr = mmap(NULL, 512*PAGE_SIZE, ...);
	mlock(ptr, 512*PAGE_SIZE);
	fork();
	munmap(ptr + 100 * PAGE_SIZE, PAGE_SIZE);

I'd expect to get two processes, each mapping the same compound THP, one
with a PMD and the other with 511 ptes and one hole.  Is there something
different that goes on?

[toc] | [prev] | [next] | [standalone]

#1335226 — Re: [PATCHv2 04/28] mm: make remove_migration_ptes() beyond mm/migration.c

On Fri, Feb 12, 2016 at 08:54:58AM -0800, Dave Hansen wrote:
> On 02/11/2016 06:21 AM, Kirill A. Shutemov wrote
> > We also shouldn't try to mlock() pte-mapped huge pages: pte-mapeed THP
> > pages are never mlocked.
> 
> That's kinda subtle.  Can you explain more?
> 
> If we did the following:
> 
> 	ptr = mmap(NULL, 512*PAGE_SIZE, ...);
> 	mlock(ptr, 512*PAGE_SIZE);
> 	fork();
> 	munmap(ptr + 100 * PAGE_SIZE, PAGE_SIZE);
> 
> I'd expect to get two processes, each mapping the same compound THP, one
> with a PMD and the other with 511 ptes and one hole.  Is there something
> different that goes on?

I'm not sure what exactly you want to ask with this code, but it will have
the following result:

 - After fork() process will split the pmd in munlock(). For file thp
   split pmd, means clear it out. Mapping split_huge_pmd() would munlock
   the page as we do for anon thp;

 - In child process the page is never mapped as mlock() is not inherited
   and we don't copy page tables for shared VMA as they can re-faulted
   later;

The basic semantic for mlock()ed file THP would be the same as for anon
THP: we only keep the page mlocked as long as it's mapped only with PMDs.
This way it's relatively simple to make sure that we don't leak mlocked
pages.

-- 
 Kirill A. Shutemov

[toc] | [prev] | [next] | [standalone]

#1335532 — Re: [PATCHv2 04/28] mm: make remove_migration_ptes() beyond mm/migration.c

On 02/16/2016 01:54 AM, Kirill A. Shutemov wrote:
> On Fri, Feb 12, 2016 at 08:54:58AM -0800, Dave Hansen wrote:
>> On 02/11/2016 06:21 AM, Kirill A. Shutemov wrote
>>> We also shouldn't try to mlock() pte-mapped huge pages: pte-mapeed THP
>>> pages are never mlocked.
>>
>> That's kinda subtle.  Can you explain more?
>>
>> If we did the following:
>>
>> 	ptr = mmap(NULL, 512*PAGE_SIZE, ...);
>> 	mlock(ptr, 512*PAGE_SIZE);
>> 	fork();
>> 	munmap(ptr + 100 * PAGE_SIZE, PAGE_SIZE);
>>
>> I'd expect to get two processes, each mapping the same compound THP, one
>> with a PMD and the other with 511 ptes and one hole.  Is there something
>> different that goes on?
> 
> I'm not sure what exactly you want to ask with this code, but it will have
> the following result:
> 
>  - After fork() process will split the pmd in munlock(). For file thp
>    split pmd, means clear it out. Mapping split_huge_pmd() would munlock
>    the page as we do for anon thp;
> 
>  - In child process the page is never mapped as mlock() is not inherited
>    and we don't copy page tables for shared VMA as they can re-faulted
>    later;

Huh, I didn't realize we don't inherit mlock() across fork(). Learn
something every day!

> The basic semantic for mlock()ed file THP would be the same as for anon
> THP: we only keep the page mlocked as long as it's mapped only with PMDs.
> This way it's relatively simple to make sure that we don't leak mlocked
> pages.

Ahh, I forgot about that bit.  Could you add some of that description to
the changelog so I don't forget again?

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web