Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1332042 > unrolled thread
| Started by | "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> |
|---|---|
| First post | 2016-02-11 15:30 +0100 |
| Last post | 2016-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.
[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
| From | "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> |
|---|---|
| Date | 2016-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]
| From | Dave Hansen <dave.hansen@intel.com> |
|---|---|
| Date | 2016-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]
| From | "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> |
|---|---|
| Date | 2016-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]
| From | Dave Hansen <dave.hansen@intel.com> |
|---|---|
| Date | 2016-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]
| From | "Kirill A. Shutemov" <kirill@shutemov.name> |
|---|---|
| Date | 2016-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