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


Groups > linux.kernel > #1332042 > unrolled thread

[PATCHv2 17/28] thp: skip file huge pmd on copy_huge_pmd()

Started by"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
First post2016-02-11 15:30 +0100
Last post2016-02-18 13:50 +0100
Articles 5 — 3 participants

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 17/28] thp: skip file huge pmd on copy_huge_pmd() "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-02-11 15:30 +0100
    Re: [PATCHv2 17/28] thp: skip file huge pmd on copy_huge_pmd() Dave Hansen <dave.hansen@intel.com> - 2016-02-12 19:50 +0100
      Re: [PATCHv2 17/28] thp: skip file huge pmd on copy_huge_pmd() "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-02-16 11:20 +0100
        Re: [PATCHv2 17/28] thp: skip file huge pmd on copy_huge_pmd() Dave Hansen <dave.hansen@intel.com> - 2016-02-16 16:50 +0100
          Re: [PATCHv2 17/28] thp: skip file huge pmd on copy_huge_pmd() "Kirill A. Shutemov" <kirill@shutemov.name> - 2016-02-18 13:50 +0100

#1332042 — [PATCHv2 17/28] thp: skip file huge pmd on copy_huge_pmd()

From"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Date2016-02-11 15:30 +0100
Subject[PATCHv2 17/28] thp: skip file huge pmd on copy_huge_pmd()
Message-ID<r10pQ-1zg-19@gated-at.bofh.it>
File pmds can be safely skip on copy_huge_pmd(), we can re-fault them
later. COW for file mappings handled on pte level.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 mm/huge_memory.c | 34 ++++++++++++++++------------------
 1 file changed, 16 insertions(+), 18 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 4da4e915af61..00f10d323039 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1052,14 +1052,15 @@ int copy_huge_pmd(struct mm_struct *dst_mm, struct mm_struct *src_mm,
 	struct page *src_page;
 	pmd_t pmd;
 	pgtable_t pgtable = NULL;
-	int ret;
+	int ret = -ENOMEM;
 
-	if (!vma_is_dax(vma)) {
-		ret = -ENOMEM;
-		pgtable = pte_alloc_one(dst_mm, addr);
-		if (unlikely(!pgtable))
-			goto out;
-	}
+	/* Skip if can be re-fill on fault */
+	if (!vma_is_anonymous(vma))
+		return 0;
+
+	pgtable = pte_alloc_one(dst_mm, addr);
+	if (unlikely(!pgtable))
+		goto out;
 
 	dst_ptl = pmd_lock(dst_mm, dst_pmd);
 	src_ptl = pmd_lockptr(src_mm, src_pmd);
@@ -1067,7 +1068,7 @@ int copy_huge_pmd(struct mm_struct *dst_mm, struct mm_struct *src_mm,
 
 	ret = -EAGAIN;
 	pmd = *src_pmd;
-	if (unlikely(!pmd_trans_huge(pmd) && !pmd_devmap(pmd))) {
+	if (unlikely(!pmd_trans_huge(pmd))) {
 		pte_free(dst_mm, pgtable);
 		goto out_unlock;
 	}
@@ -1090,16 +1091,13 @@ int copy_huge_pmd(struct mm_struct *dst_mm, struct mm_struct *src_mm,
 		goto out_unlock;
 	}
 
-	if (!vma_is_dax(vma)) {
-		/* thp accounting separate from pmd_devmap accounting */
-		src_page = pmd_page(pmd);
-		VM_BUG_ON_PAGE(!PageHead(src_page), src_page);
-		get_page(src_page);
-		page_dup_rmap(src_page, true);
-		add_mm_counter(dst_mm, MM_ANONPAGES, HPAGE_PMD_NR);
-		atomic_long_inc(&dst_mm->nr_ptes);
-		pgtable_trans_huge_deposit(dst_mm, dst_pmd, pgtable);
-	}
+	src_page = pmd_page(pmd);
+	VM_BUG_ON_PAGE(!PageHead(src_page), src_page);
+	get_page(src_page);
+	page_dup_rmap(src_page, true);
+	add_mm_counter(dst_mm, MM_ANONPAGES, HPAGE_PMD_NR);
+	atomic_long_inc(&dst_mm->nr_ptes);
+	pgtable_trans_huge_deposit(dst_mm, dst_pmd, pgtable);
 
 	pmdp_set_wrprotect(src_mm, addr, src_pmd);
 	pmd = pmd_mkold(pmd_wrprotect(pmd));
-- 
2.7.0

[toc] | [next] | [standalone]


#1333032

FromDave Hansen <dave.hansen@intel.com>
Date2016-02-12 19:50 +0100
Message-ID<r1qX0-2kB-15@gated-at.bofh.it>
In reply to#1332042
On 02/11/2016 06:21 AM, Kirill A. Shutemov wrote:
> File pmds can be safely skip on copy_huge_pmd(), we can re-fault them
> later. COW for file mappings handled on pte level.

Is this different from 4k pages?  I figured we might skip copying
file-backed ptes on fork, but I couldn't find the code.

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


#1335255

From"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Date2016-02-16 11:20 +0100
Message-ID<r2KTF-6wn-33@gated-at.bofh.it>
In reply to#1333032
On Fri, Feb 12, 2016 at 10:42:09AM -0800, Dave Hansen wrote:
> On 02/11/2016 06:21 AM, Kirill A. Shutemov wrote:
> > File pmds can be safely skip on copy_huge_pmd(), we can re-fault them
> > later. COW for file mappings handled on pte level.
> 
> Is this different from 4k pages?  I figured we might skip copying
> file-backed ptes on fork, but I couldn't find the code.

Currently, we only filter out on per-VMA basis. See first comment in
copy_page_range().

Here we handle PMD mapped file pages in COW mapping. File THP can be
mapped into COW mapping as result of read page fault.

-- 
 Kirill A. Shutemov

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


#1335569

FromDave Hansen <dave.hansen@intel.com>
Date2016-02-16 16:50 +0100
Message-ID<r2Q31-1iJ-41@gated-at.bofh.it>
In reply to#1335255
On 02/16/2016 02:14 AM, Kirill A. Shutemov wrote:
> On Fri, Feb 12, 2016 at 10:42:09AM -0800, Dave Hansen wrote:
>> On 02/11/2016 06:21 AM, Kirill A. Shutemov wrote:
>>> File pmds can be safely skip on copy_huge_pmd(), we can re-fault them
>>> later. COW for file mappings handled on pte level.
>>
>> Is this different from 4k pages?  I figured we might skip copying
>> file-backed ptes on fork, but I couldn't find the code.
> 
> Currently, we only filter out on per-VMA basis. See first comment in
> copy_page_range().
> 
> Here we handle PMD mapped file pages in COW mapping. File THP can be
> mapped into COW mapping as result of read page fault.

OK...  So, copy_page_range() has a check for "Don't copy ptes where a
page fault will fill them correctly."  Seems sane enough, but the check
is implemented using a check for the VMA having !vma->anon_vma, which is
a head-scratcher for a moment.  Why does that apply to huge tmpfs?

Ahh, MAP_PRIVATE.  MAP_PRIVATE vmas have ->anon_vma because they have
essentially-anonymous pages for when they do a COW, so they don't hit
that check and they go through the copy_*() functions, including
copy_huge_pmd().

We don't handle 2M COW operations yet so we simply decline to copy these
pages.  Might cost us page faults down the road, but it makes things
easier to implement for now.

Did I get that right?

Any chance we could get a bit of that into the patch descriptions so
that the next hapless reviewer can spend their time looking at your code
instead of relearning the fork() handling for MAP_PRIVATE?

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


#1337324

From"Kirill A. Shutemov" <kirill@shutemov.name>
Date2016-02-18 13:50 +0100
Message-ID<r3wbU-5xP-11@gated-at.bofh.it>
In reply to#1335569
On Tue, Feb 16, 2016 at 07:46:37AM -0800, Dave Hansen wrote:
> On 02/16/2016 02:14 AM, Kirill A. Shutemov wrote:
> > On Fri, Feb 12, 2016 at 10:42:09AM -0800, Dave Hansen wrote:
> >> On 02/11/2016 06:21 AM, Kirill A. Shutemov wrote:
> >>> File pmds can be safely skip on copy_huge_pmd(), we can re-fault them
> >>> later. COW for file mappings handled on pte level.
> >>
> >> Is this different from 4k pages?  I figured we might skip copying
> >> file-backed ptes on fork, but I couldn't find the code.
> > 
> > Currently, we only filter out on per-VMA basis. See first comment in
> > copy_page_range().
> > 
> > Here we handle PMD mapped file pages in COW mapping. File THP can be
> > mapped into COW mapping as result of read page fault.
> 
> OK...  So, copy_page_range() has a check for "Don't copy ptes where a
> page fault will fill them correctly."  Seems sane enough, but the check
> is implemented using a check for the VMA having !vma->anon_vma, which is
> a head-scratcher for a moment.  Why does that apply to huge tmpfs?
> 
> Ahh, MAP_PRIVATE.  MAP_PRIVATE vmas have ->anon_vma because they have
> essentially-anonymous pages for when they do a COW, so they don't hit
> that check and they go through the copy_*() functions, including
> copy_huge_pmd().
> 
> We don't handle 2M COW operations yet so we simply decline to copy these
> pages.  Might cost us page faults down the road, but it makes things
> easier to implement for now.
> 
> Did I get that right?

Yep.

> Any chance we could get a bit of that into the patch descriptions so
> that the next hapless reviewer can spend their time looking at your code
> instead of relearning the fork() handling for MAP_PRIVATE?

Sure.

-- 
 Kirill A. Shutemov

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web