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

Groups > linux.kernel > #1332037 > unrolled thread

[PATCHv2 13/28] thp: support file pages in zap_huge_pmd()

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 13/28] thp: support file pages in zap_huge_pmd() "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-02-11 15:30 +0100
    Re: [PATCHv2 13/28] thp: support file pages in zap_huge_pmd() Dave Hansen <dave.hansen@intel.com> - 2016-02-12 19:40 +0100
      Re: [PATCHv2 13/28] thp: support file pages in zap_huge_pmd() "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2016-02-16 11:10 +0100
        Re: [PATCHv2 13/28] thp: support file pages in zap_huge_pmd() Dave Hansen <dave.hansen@intel.com> - 2016-02-16 16:40 +0100
          Re: [PATCHv2 13/28] thp: support file pages in zap_huge_pmd() "Kirill A. Shutemov" <kirill@shutemov.name> - 2016-02-18 13:20 +0100

#1332037 — [PATCHv2 13/28] thp: support file pages in zap_huge_pmd()

For file pages we don't deposit page table on mapping: no need to
withdraw it.

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

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 732bda42ca80..8fd5a3c58353 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1654,10 +1654,16 @@ int zap_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma,
 		struct page *page = pmd_page(orig_pmd);
 		page_remove_rmap(page, true);
 		VM_BUG_ON_PAGE(page_mapcount(page) < 0, page);
-		add_mm_counter(tlb->mm, MM_ANONPAGES, -HPAGE_PMD_NR);
 		VM_BUG_ON_PAGE(!PageHead(page), page);
-		pte_free(tlb->mm, pgtable_trans_huge_withdraw(tlb->mm, pmd));
-		atomic_long_dec(&tlb->mm->nr_ptes);
+		if (PageAnon(page)) {
+			pgtable_t pgtable;
+			pgtable = pgtable_trans_huge_withdraw(tlb->mm, pmd);
+			pte_free(tlb->mm, pgtable);
+			atomic_long_dec(&tlb->mm->nr_ptes);
+			add_mm_counter(tlb->mm, MM_ANONPAGES, -HPAGE_PMD_NR);
+		} else {
+			add_mm_counter(tlb->mm, MM_FILEPAGES, -HPAGE_PMD_NR);
+		}
 		spin_unlock(ptl);
 		tlb_remove_page(tlb, page);
 	}
-- 
2.7.0

[toc] | [next] | [standalone]

#1333025

On 02/11/2016 06:21 AM, Kirill A. Shutemov wrote:
> For file pages we don't deposit page table on mapping: no need to
> withdraw it.

I thought the deposit thing was to guarantee we could always do a PMD
split.  It still seems like if you wanted to split a huge-tmpfs page,
you'd need to first split the PMD which might need the deposited one.

Why not?

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

#1335227

On Fri, Feb 12, 2016 at 10:33:37AM -0800, Dave Hansen wrote:
> On 02/11/2016 06:21 AM, Kirill A. Shutemov wrote:
> > For file pages we don't deposit page table on mapping: no need to
> > withdraw it.
> 
> I thought the deposit thing was to guarantee we could always do a PMD
> split.  It still seems like if you wanted to split a huge-tmpfs page,
> you'd need to first split the PMD which might need the deposited one.
> 
> Why not?

For file thp, split_huge_pmd() is implemented by clearing out the pmd: we
can setup and fill pte table later. Therefore no need to deposit page
table -- we would not use it. DAX does the same.

-- 
 Kirill A. Shutemov

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

#1335531

On 02/16/2016 02:00 AM, Kirill A. Shutemov wrote:
> On Fri, Feb 12, 2016 at 10:33:37AM -0800, Dave Hansen wrote:
>> On 02/11/2016 06:21 AM, Kirill A. Shutemov wrote:
>>> For file pages we don't deposit page table on mapping: no need to
>>> withdraw it.
>>
>> I thought the deposit thing was to guarantee we could always do a PMD
>> split.  It still seems like if you wanted to split a huge-tmpfs page,
>> you'd need to first split the PMD which might need the deposited one.
>>
>> Why not?
> 
> For file thp, split_huge_pmd() is implemented by clearing out the pmd: we
> can setup and fill pte table later. Therefore no need to deposit page
> table -- we would not use it. DAX does the same.

Ahh...  Do we just never split in any fault contexts, or do we just
retry the fault?

In any case, that seems like fine enough (although subtle) behavior.
Can you call it out a bit more explicitly in the patch text?

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

#1337307

On Tue, Feb 16, 2016 at 07:31:58AM -0800, Dave Hansen wrote:
> On 02/16/2016 02:00 AM, Kirill A. Shutemov wrote:
> > On Fri, Feb 12, 2016 at 10:33:37AM -0800, Dave Hansen wrote:
> >> On 02/11/2016 06:21 AM, Kirill A. Shutemov wrote:
> >>> For file pages we don't deposit page table on mapping: no need to
> >>> withdraw it.
> >>
> >> I thought the deposit thing was to guarantee we could always do a PMD
> >> split.  It still seems like if you wanted to split a huge-tmpfs page,
> >> you'd need to first split the PMD which might need the deposited one.
> >>
> >> Why not?
> > 
> > For file thp, split_huge_pmd() is implemented by clearing out the pmd: we
> > can setup and fill pte table later. Therefore no need to deposit page
> > table -- we would not use it. DAX does the same.
> 
> Ahh...  Do we just never split in any fault contexts, or do we just
> retry the fault?

In fault contexts we would just continue fault handling as if we had
pmd_none().

-- 
 Kirill A. Shutemov

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web