Transparent Hugepage support #7
Subsystems (23)
PATCH 1/1 Transparent Hugepage support #7
Hello,
this is an update that notably fixes one bug in split_huge_page_mm/vma that was calling find_vma on "address+HPAGE_PMD_SIZE-1" even if address wasn't always hpage aligned, so it was failing on the last hugepage of the vma unless "address" was hugepage aligned (firefox flash tripped on this last night, but thanks to the amount of BUG_ON that I added it was immediate to fix). No more problems with java applets, flash etc...
This also moves the MADV_HUGEPAGE to 15 to avoid tripping on parisc (this is just in case, no idea if parisc is planning to support transparent hugepage or not). Not sure why there's not just one file for all MADV_ defines, there are 4 billions of madv possible with this api so it looks unnecessary to have per-arch defines.
So this is running fine, no more bugchecks tripping on mprotect and laptop was rock solid so far.
14:45:10 up 15:10, 5 users, load average: 0.22, 0.17, 0.06
AnonPages: 612988 kB
AnonHugePages: 65536 kB
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 add pmd mmu_notifier helpers
From: Andrea Arcangeli <[email protected]>
Add mmu notifier helpers to handle pmd huge operations.
---
include/linux/mmu_notifier.h +40 -0
@@ -243,6 +243,32 @@ static inline void mmu_notifier_mm_destr __pte; \ }) +#define pmdp_clear_flush_notify (__vma, __address, __pmdp) \ +({ \ + pmd_t __pmd; \ + struct vm_area_struct *___vma = __vma; \ + unsigned long ___address = __address; \ + VM_BUG_ON(__address & ~HPAGE_PMD_MASK); \ + mmu_notifier_invalidate_range_start(___vma->vm_mm, ___address, \ + (__address)+HPAGE_PMD_SIZE);\ + __pmd = pmdp_clear_flush(___vma, ___address, __pmdp); \ + mmu_notifier_invalidate_range_end(___vma->vm_mm, ___address, \ + (__address)+HPAGE_PMD_SIZE); \ + __pmd; \ +}) + +#define pmdp_splitting_flush_notify (__vma, __address, __pmdp) \ +({ \ + struct vm_area_struct *___vma = __vma; \ + unsigned long ___address = __address; \ + VM_BUG_ON(__address & ~HPAGE_PMD_MASK); \ + mmu_notifier_invalidate_range_start(___vma->vm_mm, ___address, \ + (__address)+HPAGE_PMD_SIZE);\ + pmdp_splitting_flush(___vma, ___address, __pmdp); \ + mmu_notifier_invalidate_range_end(___vma->vm_mm, ___address, \ + (__address)+HPAGE_PMD_SIZE); \ +}) +#define ptep_clear_flush_young_notify (__vma, __address, __ptep) \ ({ \ int __young; \
@@ -254,6 +280,17 @@ static inline void mmu_notifier_mm_destr __young; \ }) +#define pmdp_clear_flush_young_notify (__vma, __address, __pmdp) \ +({ \ + int __young; \ + struct vm_area_struct *___vma = __vma; \ + unsigned long ___address = __address; \ + __young = pmdp_clear_flush_young(___vma, ___address, __pmdp); \ + __young |= mmu_notifier_clear_flush_young(___vma->vm_mm, \ + ___address); \ + __young; \ +}) +#define set_pte_at_notify (__mm, __address, __ptep, __pte) \ ({ \ struct mm_struct *___mm = __mm; \
@@ -305,7 +342,10 @@ static inline void mmu_notifier_mm_destr }#define ptep_clear_flush_young_notify ptep_clear_flush_young +#define pmdp_clear_flush_young_notify pmdp_clear_flush_young#define ptep_clear_flush_notify ptep_clear_flush +#define pmdp_clear_flush_notify pmdp_clear_flush +#define pmdp_splitting_flush_notify pmdp_splitting_flush#define set_pte_at_notify set_pte_at#endif /* CONFIG_MMU_NOTIFIER */
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 18 of 31] add pmd mmu_notifier helpers
Quoted 5 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Add mmu notifier helpers to handle pmd huge operations.
Signed-off-by Andrea Arcangeli<[email protected]>
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 split_huge_page paging
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Paging logic that splits the page before it is unmapped and added to swap to ensure backwards compatibility with the legacy swap code. Eventually swap should natively pageout the hugepages to increase performance and decrease seeking and fragmentation of swap space. swapoff can just skip over huge pmd as they cannot be part of swap yet. In add_to_swap be careful to split the page only if we got a valid swap entry so we don't split hugepages with a full swap.
---
mm/memory-failure.c +2 -0
@@ -378,6 +378,8 @@ static void collect_procs_anon(struct pastruct task_struct *tsk;struct anon_vma *av; +if (unlikely (split_huge_page (page))) +return ;read_lock (&tasklist_lock); av =page_lock_anon_vma (page);if (av ==NULL )/* Not actually mapped anymore */
mm/rmap.c +1 -0
@@ -1174,6 +1174,7 @@ int try_to_unmap(struct page *page, enumint ret;BUG_ON (!PageLocked (page)); +BUG_ON (PageTransHuge (page));if (unlikely (PageKsm (page))) ret =try_to_unmap_ksm (page, flags);
mm/swap_state.c +6 -0
@@ -156,6 +156,12 @@ int add_to_swap(struct page *page)if (!entry.val)return 0 ; +if (unlikely (PageTransHuge (page))) +if (unlikely (split_huge_page (page))) { +swapcache_free (entry,NULL ); +return 0 ; + } +/* * Radix-tree node allocations from PF_MEMALLOC contexts could * completely exhaust the page allocator. __GFP_NOMEMALLOC
mm/swapfile.c +2 -0
@@ -905,6 +905,8 @@ static inline int unuse_pmd_range(struct pmd =pmd_offset (pud, addr); do { next = pmd_addr_end(addr, end); + if (unlikely(pmd_trans_huge(*pmd))) + continue; if (pmd_none_or_clear_bad(pmd)) continue; ret = unuse_pte_range(vma, pmd, addr, next, entry, page);
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 22 of 31] split_huge_page paging
Quoted 41 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Paging logic that splits the page before it is unmapped and added to swap to ensure backwards compatibility with the legacy swap code. Eventually swap should natively pageout the hugepages to increase performance and decrease seeking and fragmentation of swap space. swapoff can just skip over huge pmd as they cannot be part of swap yet. In
add_to_swapbe careful to split the page only if we got a valid swap entry so we don't split hugepages with a full swap.Signed-off-by Andrea Arcangeli<[email protected]>---
mm/memory-failure.c +2
-0@@ -378,6 +378,8 @@ static void collect_procs_anon(struct pastruct task_struct *tsk;struct anon_vma *av; +if (unlikely (split_huge_page (page))) +return ;read_lock (&tasklist_lock); av =page_lock_anon_vma (page);if (av ==NULL )/* Not actually mapped anymore */ mm/rmap.c +1
-0@@ -1174,6 +1174,7 @@ int try_to_unmap(struct page *page, enumint ret;BUG_ON (!PageLocked (page)); +BUG_ON (PageTransHuge (page));if (unlikely (PageKsm (page))) ret =try_to_unmap_ksm (page, flags);mm/swap_state.c +0
-0@@ -156,6 +156,12 @@ int add_to_swap(struct page *page)if (!entry.val)return 0 ;
mm/swap_state.c int add_to_swap(struct page *page) · line 167
Quoted 10 lines
mm/swap_state.c +6
-0+if (unlikely (PageTransHuge (page))) +if (unlikely (split_huge_page (page))) { +swapcache_free (entry,NULL ); +return 0 ; + } +/* * Radix-tree node allocations from PF_MEMALLOC contexts could * completely exhaust the page allocator. __GFP_NOMEMALLOC
Shouldn't we split up these pages in vmscan.c, before calling add_to_swap() ?
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 22 of 31] split_huge_page paging
Quoted 2 lines · Rik van Riel
Shouldn't we split up these pages in
vmscan.c, before callingadd_to_swap()?
In theory it would work, but for khugepaged to be safe, I'm relying on either mmap_sem write mode, or PG_lock taken, so split_huge_page has to run either with mmap_sem read/write mode or PG_lock taken. Calling it from isolate_lru_page would make locking more complicated, in addition to that split_huge_page would deadlock if called by __isolate_lru_page because it has to take the lru lock to add the tail pages to the lru and I didn't want to risk with a __split_huge_page variant that works while holding lru_lock.
I'll add the above to patch comment.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 22 of 31] split_huge_page paging
In reply to Andrea ArcangeliQuoted 6 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
Paging logic that splits the page before it is unmapped and added to swap to ensure backwards compatibility with the legacy swap code. Eventually swap should natively pageout the hugepages to increase performance and decrease seeking and fragmentation of swap space.
To be honest, I'm not sure how much of a win that would even be. SWAP_CLUSTER_MAX number of pages is 128K on x86-64 which is far short of the 2MB. There is no guarantee that the cost of 2M-128K of potentialy unnecessary IO to satisfy a watermark would be offset by seekier swap or fragmentation of swap space. Even if it was, it would make sense to try and fix swap-layout so that virtually-contiguous pages are swap-contiguous. Just splitting the page and swapping out what's necessary seems reasonable on its own.
Quoted 5 lines
swapoff can just skip over huge pmd as
they cannot be part of swap yet. Inadd_to_swapbe careful to split the page only if we got a valid swap entry so we don't split hugepages with a full swap.Signed-off-by Andrea Arcangeli <[email protected]>
Quoted 54 lines
---
mm/memory-failure.c +2
-0@@ -378,6 +378,8 @@ static void collect_procs_anon(struct pastruct task_struct *tsk;struct anon_vma *av; +if (unlikely (split_huge_page (page))) +return ;read_lock (&tasklist_lock); av =page_lock_anon_vma (page);if (av ==NULL )/* Not actually mapped anymore */ mm/rmap.c +1
-0@@ -1174,6 +1174,7 @@ int try_to_unmap(struct page *page, enumint ret;BUG_ON (!PageLocked (page)); +BUG_ON (PageTransHuge (page));if (unlikely (PageKsm (page))) ret =try_to_unmap_ksm (page, flags);mm/swap_state.c +6
-0@@ -156,6 +156,12 @@ int add_to_swap(struct page *page)if (!entry.val)return 0 ; +if (unlikely (PageTransHuge (page))) +if (unlikely (split_huge_page (page))) { +swapcache_free (entry,NULL ); +return 0 ; + } +/* * Radix-tree node allocations from PF_MEMALLOC contexts could * completely exhaust the page allocator. __GFP_NOMEMALLOC mm/swapfile.c +2
-0@@ -905,6 +905,8 @@ static inline int unuse_pmd_range(struct pmd =pmd_offset (pud, addr); do { next = pmd_addr_end(addr, end); + if (unlikely(pmd_trans_huge(*pmd))) + continue; if (pmd_none_or_clear_bad(pmd)) continue; ret = unuse_pte_range(vma, pmd, addr, next, entry, page);
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 kvm mmu transparent hugepage support
In reply to Andrea ArcangeliFrom: Marcelo Tosatti <[email protected]>
This should work for both hugetlbfs and transparent hugepages.
---
arch/x86/kvm/mmu.c +9 -0
@@ -489,6 +489,15 @@ static int host_mapping_level(struct kvm out:up_read (¤t->mm->mmap_sem); +/* check for transparent hugepages */ +if (page_size ==PAGE_SIZE ) { +struct page *page =gfn_to_page (kvm, gfn); + +if (!is_error_page (page) &&PageHead (page)) + page_size =KVM_HPAGE_SIZE (2 ); +kvm_release_page_clean (page); + } +for (i =PT_PAGE_TABLE_LEVEL ; i < (PT_PAGE_TABLE_LEVEL +KVM_NR_PAGE_SIZES ); ++i) {if (page_size >=KVM_HPAGE_SIZE (i))
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 24 of 31] kvm mmu transparent hugepage support
Quoted 6 lines · Andrea Arcangeli
From: Marcelo Tosatti<[email protected]>
This should work for both hugetlbfs and transparent hugepages.
Signed-off-by Andrea Arcangeli<[email protected]>Signed-off-by Marcelo Tosatti<[email protected]>
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 add pmd paravirt ops
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Paravirt ops pmd_update/pmd_update_defer/pmd_set_at. Not all might be necessary (vmware needs pmd_update, Xen needs set_pmd_at, nobody needs pmd_update_defer), but this is to keep full simmetry with pte paravirt ops, which looks cleaner and simpler from a common code POV.
---
arch/x86/include/asm/paravirt.h +23 -0
@@ -449,6 +449,11 @@ static inline void pte_update(struct mm_ {PVOP_VCALL3 (pv_mmu_ops.pte_update, mm, addr, ptep); } +static inline void pmd_update (struct mm_struct *mm,unsigned long addr, +pmd_t *pmdp) +{ +PVOP_VCALL3 (pv_mmu_ops.pmd_update, mm, addr, pmdp); +}static inline void pte_update_defer (struct mm_struct *mm,unsigned long addr,pte_t *ptep)
@@ -456,6 +461,12 @@ static inline void pte_update_defer(struPVOP_VCALL3 (pv_mmu_ops.pte_update_defer, mm, addr, ptep); } +static inline void pmd_update_defer (struct mm_struct *mm,unsigned long addr, +pmd_t *pmdp) +{ +PVOP_VCALL3 (pv_mmu_ops.pmd_update_defer, mm, addr, pmdp); +} +static inline pte_t __pte (pteval_t val) {pteval_t ret;
@@ -557,6 +568,18 @@ static inline void set_pte_at(struct mm_PVOP_VCALL4 (pv_mmu_ops.set_pte_at, mm, addr, ptep, pte.pte); } +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +static inline void set_pmd_at (struct mm_struct *mm,unsigned long addr, +pmd_t *pmdp,pmd_t pmd) +{ +if (sizeof (pmdval_t) >sizeof (long )) +/* 5 arg words */ + pv_mmu_ops.set_pmd_at (mm, addr, pmdp, pmd); +else +PVOP_VCALL4 (pv_mmu_ops.set_pmd_at, mm, addr, pmdp, pmd.pmd); +} +#endif +static inline void set_pmd (pmd_t *pmdp,pmd_t pmd) {pmdval_t val =native_pmd_val (pmd);
arch/x86/include/asm/paravirt_types.h +6 -0
@@ -266,10 +266,16 @@ struct pv_mmu_ops {void (*set_pte_at)(struct mm_struct *mm,unsigned long addr,pte_t *ptep,pte_t pteval);void (*set_pmd)(pmd_t *pmdp,pmd_t pmdval); +void (*set_pmd_at)(struct mm_struct *mm,unsigned long addr, +pmd_t *pmdp,pmd_t pmdval);void (*pte_update)(struct mm_struct *mm,unsigned long addr,pte_t *ptep);void (*pte_update_defer)(struct mm_struct *mm,unsigned long addr,pte_t *ptep); +void (*pmd_update)(struct mm_struct *mm,unsigned long addr, +pmd_t *pmdp); +void (*pmd_update_defer)(struct mm_struct *mm, +unsigned long addr,pmd_t *pmdp);pte_t (*ptep_modify_prot_start)(struct mm_struct *mm,unsigned long addr,pte_t *ptep);
arch/x86/kernel/paravirt.c +3 -0
@@ -422,8 +422,11 @@ struct pv_mmu_ops pv_mmu_ops = { .set_pte = native_set_pte, .set_pte_at = native_set_pte_at, .set_pmd = native_set_pmd, + .set_pmd_at = native_set_pmd_at, .pte_update = paravirt_nop, .pte_update_defer = paravirt_nop, + .pmd_update = paravirt_nop, + .pmd_update_defer = paravirt_nop, .ptep_modify_prot_start = __ptep_modify_prot_start, .ptep_modify_prot_commit = __ptep_modify_prot_commit,
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 08 of 31] add pmd paravirt ops
Quoted 8 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Paravirt ops pmd_update/pmd_update_defer/pmd_set_at. Not all might be necessary (vmware needs
pmd_update, Xen needsset_pmd_at, nobody needspmd_update_defer), but this is to keep full simmetry with pte paravirt ops, which looks cleaner and simpler from a common code POV.Signed-off-by Andrea Arcangeli<[email protected]>
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 08 of 31] add pmd paravirt ops
In reply to Andrea ArcangeliQuoted 8 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
Paravirt ops pmd_update/pmd_update_defer/pmd_set_at. Not all might be necessary (vmware needs
pmd_update, Xen needsset_pmd_at, nobody needspmd_update_defer), but this is to keep full simmetry with pte paravirt ops, which looks cleaner and simpler from a common code POV.Signed-off-by Andrea Arcangeli <[email protected]>
Quoted 85 lines
---
arch/x86/include/asm/paravirt.h +23
-0@@ -449,6 +449,11 @@ static inline void pte_update(struct mm_ {PVOP_VCALL3 (pv_mmu_ops.pte_update, mm, addr, ptep); } +static inline void pmd_update (struct mm_struct *mm,unsigned long addr, +pmd_t *pmdp) +{ +PVOP_VCALL3 (pv_mmu_ops.pmd_update, mm, addr, pmdp); +}static inline void pte_update_defer (struct mm_struct *mm,unsigned long addr,pte_t *ptep)@@ -456,6 +461,12 @@ static inline void pte_update_defer(struPVOP_VCALL3 (pv_mmu_ops.pte_update_defer, mm, addr, ptep); } +static inline void pmd_update_defer (struct mm_struct *mm,unsigned long addr, +pmd_t *pmdp) +{ +PVOP_VCALL3 (pv_mmu_ops.pmd_update_defer, mm, addr, pmdp); +} +static inline pte_t __pte (pteval_t val) {pteval_t ret;@@ -557,6 +568,18 @@ static inline void set_pte_at(struct mm_PVOP_VCALL4 (pv_mmu_ops.set_pte_at, mm, addr, ptep, pte.pte); } +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +static inline void set_pmd_at (struct mm_struct *mm,unsigned long addr, +pmd_t *pmdp,pmd_t pmd) +{ +if (sizeof (pmdval_t) >sizeof (long )) +/* 5 arg words */ + pv_mmu_ops.set_pmd_at (mm, addr, pmdp, pmd); +else +PVOP_VCALL4 (pv_mmu_ops.set_pmd_at, mm, addr, pmdp, pmd.pmd); +} +#endif +static inline void set_pmd (pmd_t *pmdp,pmd_t pmd) {pmdval_t val =native_pmd_val (pmd);arch/x86/include/asm/paravirt_types.h +6
-0@@ -266,10 +266,16 @@ struct pv_mmu_ops {void (*set_pte_at)(struct mm_struct *mm,unsigned long addr,pte_t *ptep,pte_t pteval);void (*set_pmd)(pmd_t *pmdp,pmd_t pmdval); +void (*set_pmd_at)(struct mm_struct *mm,unsigned long addr, +pmd_t *pmdp,pmd_t pmdval);void (*pte_update)(struct mm_struct *mm,unsigned long addr,pte_t *ptep);void (*pte_update_defer)(struct mm_struct *mm,unsigned long addr,pte_t *ptep); +void (*pmd_update)(struct mm_struct *mm,unsigned long addr, +pmd_t *pmdp); +void (*pmd_update_defer)(struct mm_struct *mm, +unsigned long addr,pmd_t *pmdp);pte_t (*ptep_modify_prot_start)(struct mm_struct *mm,unsigned long addr,pte_t *ptep);arch/x86/kernel/paravirt.c +3
-0@@ -422,8 +422,11 @@ struct pv_mmu_ops pv_mmu_ops = { .set_pte = native_set_pte, .set_pte_at = native_set_pte_at, .set_pmd = native_set_pmd, + .set_pmd_at = native_set_pmd_at, .pte_update = paravirt_nop, .pte_update_defer = paravirt_nop, + .pmd_update = paravirt_nop, + .pmd_update_defer = paravirt_nop, .ptep_modify_prot_start = __ptep_modify_prot_start, .ptep_modify_prot_commit = __ptep_modify_prot_commit,
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 bail out gup_fast on splitting pmd
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Force gup_fast to take the slow path and block if the pmd is splitting, not only if it's none.
---
arch/x86/mm/gup.c +12 -1
@@ -156,7 +156,18 @@ static int gup_pmd_range(pud_t pud, unsipmd_t pmd = *pmdp; next =pmd_addr_end (addr, end); -if (pmd_none (pmd)) +/* +* The pmd_trans_splitting() check below explains why +* pmdp_splitting_flush has to flush the tlb, to stop +* this gup-fast code from running while we set the +* splitting bit in the pmd. Returning zero will take +* the slow path that will call wait_split_huge_page() +* if the pmd is still in splitting state. gup-fast +* can't because it has irq disabled and +* wait_split_huge_page() would never return as the +* tlb flush IPI wouldn't run. +*/ +if (pmd_none (pmd) ||pmd_trans_splitting (pmd))return 0 ;if (unlikely (pmd_large (pmd))) {if (!gup_huge_pmd (pmd, addr, next, write, pages, nr))
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 16 of 31] bail out gup_fast on splitting pmd
Quoted 6 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Force
gup_fastto take the slow path and block if the pmd is splitting, not only if it's none.Signed-off-by Andrea Arcangeli<[email protected]>
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 16 of 31] bail out gup_fast on splitting pmd
In reply to Andrea ArcangeliQuoted 6 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
Force
gup_fastto take the slow path and block if the pmd is splitting, not only if it's none.Signed-off-by Andrea Arcangeli <[email protected]>
Quoted 26 lines
---
arch/x86/mm/gup.c +12
-1@@ -156,7 +156,18 @@ static int gup_pmd_range(pud_t pud, unsipmd_t pmd = *pmdp; next =pmd_addr_end (addr, end); -if (pmd_none (pmd)) +/* +* The pmd_trans_splitting() check below explains why +* pmdp_splitting_flush has to flush the tlb, to stop +* this gup-fast code from running while we set the +* splitting bit in the pmd. Returning zero will take +* the slow path that will call wait_split_huge_page() +* if the pmd is still in splitting state. gup-fast +* can't because it has irq disabled and +* wait_split_huge_page() would never return as the +* tlb flush IPI wouldn't run. +*/ +if (pmd_none (pmd) ||pmd_trans_splitting (pmd))return 0 ;if (unlikely (pmd_large (pmd))) {if (!gup_huge_pmd (pmd, addr, next, write, pages, nr))
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 clear_copy_huge_page
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Move the copy/clear_huge_page functions to common code to share between hugetlb.c and huge_memory.c.
---
include/linux/mm.h +9 -0
@@ -1386,5 +1386,14 @@ extern void shake_page(struct page *p, iextern atomic_long_t mce_bad_pages;extern int soft_offline_page (struct page *page,int flags); +#if defined(CONFIG_TRANSPARENT_HUGEPAGE ) || defined(CONFIG_HUGETLBFS ) +extern void clear_huge_page (struct page *page, +unsigned long addr, +unsigned int pages_per_huge_page); +extern void copy_huge_page (struct page *dst,struct page *src, +unsigned long addr,struct vm_area_struct *vma, +unsigned int pages_per_huge_page); +#endif /* CONFIG_TRANSPARENT_HUGEPAGE || CONFIG_HUGETLBFS */ +#endif /* __KERNEL__ */ #endif /* _LINUX_MM_H */
mm/hugetlb.c +2 -65
79 lines not on this page · raw message
mm/memory.c +70 -0
73 lines not on this page · raw message
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 23 of 31] clear_copy_huge_page
Quoted 6 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Move the copy/clear_huge_page functions to common code to share between
hugetlb.candhuge_memory.c.Signed-off-by Andrea Arcangeli<[email protected]>
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 23 of 31] clear_copy_huge_page
In reply to Andrea ArcangeliQuoted 6 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
Move the copy/clear_huge_page functions to common code to share between
hugetlb.candhuge_memory.c.Signed-off-by Andrea Arcangeli <[email protected]>
Quoted 182 lines
---
include/linux/mm.h +9
-0@@ -1386,5 +1386,14 @@ extern void shake_page(struct page *p, iextern atomic_long_t mce_bad_pages;extern int soft_offline_page (struct page *page,int flags); +#if defined(CONFIG_TRANSPARENT_HUGEPAGE ) || defined(CONFIG_HUGETLBFS ) +extern void clear_huge_page (struct page *page, +unsigned long addr, +unsigned int pages_per_huge_page); +extern void copy_huge_page (struct page *dst,struct page *src, +unsigned long addr,struct vm_area_struct *vma, +unsigned int pages_per_huge_page); +#endif /* CONFIG_TRANSPARENT_HUGEPAGE || CONFIG_HUGETLBFS */ +#endif /* __KERNEL__ */ #endif /* _LINUX_MM_H */ mm/hugetlb.c +2
-65@@ -385,70 +385,6 @@ static int vma_has_reserves(struct vm_arreturn 0 ; } -static void clear_gigantic_page (struct page *page, -unsigned long addr,unsigned long sz) -{ -int i; -struct page *p = page; - -might_sleep (); -for (i =0 ; i < sz/PAGE_SIZE ; i++, p =mem_map_next (p, page, i)) { -cond_resched (); -clear_user_highpage (p, addr + i *PAGE_SIZE ); - } -} -static void clear_huge_page (struct page *page, -unsigned long addr,unsigned long sz) -{ -int i; - -if (unlikely (sz/PAGE_SIZE >MAX_ORDER_NR_PAGES )) { -clear_gigantic_page (page, addr, sz); -return ; - } - -might_sleep (); -for (i =0 ; i < sz/PAGE_SIZE ; i++) { -cond_resched (); -clear_user_highpage (page + i, addr + i *PAGE_SIZE ); - } -} - -static void copy_gigantic_page (struct page *dst,struct page *src, -unsigned long addr,struct vm_area_struct *vma) -{ -int i; -struct hstate *h =hstate_vma (vma); -struct page *dst_base = dst; -struct page *src_base = src; -might_sleep (); -for (i =0 ; i <pages_per_huge_page (h); ) { -cond_resched (); -copy_user_highpage (dst, src, addr + i*PAGE_SIZE , vma); - - i++; - dst =mem_map_next (dst, dst_base, i); - src =mem_map_next (src, src_base, i); - } -} -static void copy_huge_page (struct page *dst,struct page *src, -unsigned long addr,struct vm_area_struct *vma) -{ -int i; -struct hstate *h =hstate_vma (vma); - -if (unlikely (pages_per_huge_page (h) >MAX_ORDER_NR_PAGES )) { -copy_gigantic_page (dst, src, addr, vma); -return ; - } - -might_sleep (); -for (i =0 ; i <pages_per_huge_page (h); i++) { -cond_resched (); -copy_user_highpage (dst + i, src + i, addr + i*PAGE_SIZE , vma); - } -} -static void enqueue_huge_page (struct hstate *h,struct page *page) {int nid =page_to_nid (page);@@ -2334,7 +2270,8 @@ retry_avoidcopy:return -PTR_ERR (new_page); } -copy_huge_page (new_page, old_page, address, vma); +copy_huge_page (new_page, old_page, address, vma, +pages_per_huge_page (h));__SetPageUptodate (new_page);/* mm/memory.c +70
-0@@ -3396,3 +3396,73 @@ void might_fault(void) }EXPORT_SYMBOL (might_fault);#endif + +#if defined(CONFIG_TRANSPARENT_HUGEPAGE ) || defined(CONFIG_HUGETLBFS ) +static void clear_gigantic_page (struct page *page, +unsigned long addr, +unsigned int pages_per_huge_page) +{ +int i; +struct page *p = page; + +might_sleep (); +for (i =0 ; i < pages_per_huge_page; + i++, p =mem_map_next (p, page, i)) { +cond_resched (); +clear_user_highpage (p, addr + i *PAGE_SIZE ); + } +} +void clear_huge_page (struct page *page, +unsigned long addr,unsigned int pages_per_huge_page) +{ +int i; + +if (unlikely (pages_per_huge_page >MAX_ORDER_NR_PAGES )) { +clear_gigantic_page (page, addr, pages_per_huge_page); +return ; + } + +might_sleep (); +for (i =0 ; i < pages_per_huge_page; i++) { +cond_resched (); +clear_user_highpage (page + i, addr + i *PAGE_SIZE ); + } +} + +static void copy_gigantic_page (struct page *dst,struct page *src, +unsigned long addr, +struct vm_area_struct *vma, +unsigned int pages_per_huge_page) +{ +int i; +struct page *dst_base = dst; +struct page *src_base = src; +might_sleep (); +for (i =0 ; i < pages_per_huge_page; ) { +cond_resched (); +copy_user_highpage (dst, src, addr + i*PAGE_SIZE , vma); + + i++; + dst =mem_map_next (dst, dst_base, i); + src =mem_map_next (src, src_base, i); + } +} +void copy_huge_page (struct page *dst,struct page *src, +unsigned long addr,struct vm_area_struct *vma, +unsigned int pages_per_huge_page) +{ +int i; + +if (unlikely (pages_per_huge_page >MAX_ORDER_NR_PAGES )) { +copy_gigantic_page (dst, src, addr, vma, pages_per_huge_page); +return ; + } + +might_sleep (); +for (i =0 ; i < pages_per_huge_page; i++) { +cond_resched (); +copy_user_highpage (dst + i, src + i, addr + i*PAGE_SIZE , + vma); + } +} +#endif /* CONFIG_TRANSPARENT_HUGEPAGE || CONFIG_HUGETLBFS */
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 add pmd_huge_pte to mm_struct
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
This increase the size of the mm struct a bit but it is needed to preallocate one pte for each hugepage so that split_huge_page will not require a fail path. Guarantee of success is a fundamental property of split_huge_page to avoid decrasing swapping reliability and to avoid adding -ENOMEM fail paths that would otherwise force the hugepage-unaware VM code to learn rolling back in the middle of its pte mangling operations (if something we need it to learn handling pmd_trans_huge natively rather being capable of rollback). When split_huge_page runs a pte is needed to succeed the split, to map the newly splitted regular pages with a regular pte. This way all existing VM code remains backwards compatible by just adding a split_huge_page* one liner. The memory waste of those preallocated ptes is negligible and so it is worth it.
---
include/linux/mm_types.h +3 -0
@@ -291,6 +291,9 @@ struct mm_struct {#ifdef CONFIG_MMU_NOTIFIER struct mmu_notifier_mm *mmu_notifier_mm;#endif +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +pgtable_t pmd_huge_pte;/* protected by page_table_lock */ +#endif };/* Future-safe accessor for struct mm_struct's cpu_vm_mask. */
kernel/fork.c +7 -0
@@ -498,6 +498,9 @@ void __mmdrop(struct mm_struct *mm)mm_free_pgd (mm);destroy_context (mm);mmu_notifier_mm_destroy (mm); +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +VM_BUG_ON (mm->pmd_huge_pte); +#endif free_mm (mm); }EXPORT_SYMBOL_GPL (__mmdrop);
@@ -638,6 +641,10 @@ struct mm_struct *dup_mm(struct task_str mm->token_priority =0 ; mm->last_interval =0 ; +#ifdef CONFIG_TRANSPARENT_HUGEPAGE + mm->pmd_huge_pte =NULL ; +#endif +if (!mm_init (mm, tsk)) goto fail_nomem;
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 20 of 31] add pmd_huge_pte to mm_struct
Quoted 14 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
This increase the size of the mm struct a bit but it is needed to preallocate one pte for each hugepage so that
split_huge_pagewill not require a fail path. Guarantee of success is a fundamental property ofsplit_huge_pageto avoid decrasing swapping reliability and to avoid adding-ENOMEMfail paths that would otherwise force the hugepage-unaware VM code to learn rolling back in the middle of its pte mangling operations (if something we need it to learn handlingpmd_trans_hugenatively rather being capable of rollback). Whensplit_huge_pageruns a pte is needed to succeed the split, to map the newly splitted regular pages with a regular pte. This way all existing VM code remains backwards compatible by just adding a split_huge_page* one liner. The memory waste of those preallocated ptes is negligible and so it is worth it.
Quoted 1 line
Signed-off-by Andrea Arcangeli<[email protected]>
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 khugepaged
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Add khugepaged to relocate fragmented pages into hugepages if new hugepages become available. (this is indipendent of the defrag logic that will have to make new hugepages available)
---
include/linux/huge_mm.h +6 -2
@@ -25,6 +25,8 @@ enum transparent_hugepage_flag {TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG ,TRANSPARENT_HUGEPAGE_DEFRAG_FLAG ,TRANSPARENT_HUGEPAGE_DEFRAG_REQ_MADV_FLAG , +TRANSPARENT_HUGEPAGE_KHUGEPAGED_FLAG , +TRANSPARENT_HUGEPAGE_KHUGEPAGED_REQ_MADV_FLAG , #ifdef CONFIG_DEBUG_VM TRANSPARENT_HUGEPAGE_DEBUG_COW_FLAG, #endif
@@ -50,12 +52,14 @@ extern pmd_t *page_check_address_pmd(str (transparent_hugepage_flags & \ (1<<TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG) && \ (__vma)->vm_flags & VM_HUGEPAGE)) -#define transparent_hugepage_defrag (__vma) \ +#define __transparent_hugepage_defrag (__in_madv) \ (transparent_hugepage_flags & \ (1<<TRANSPARENT_HUGEPAGE_DEFRAG_FLAG) || \ (transparent_hugepage_flags & \ (1<<TRANSPARENT_HUGEPAGE_DEFRAG_REQ_MADV_FLAG) && \ - (__vma)->vm_flags & VM_HUGEPAGE)) + (__in_madv))) +#define transparent_hugepage_defrag (__vma) \ + __transparent_hugepage_defrag((__vma)->vm_flags & VM_HUGEPAGE)#ifdef CONFIG_DEBUG_VM #define transparent_hugepage_debug_cow () \ (transparent_hugepage_flags & \
include/linux/khugepaged.h new file +32 -0
@@ -0,0 +1,32 @@ +#ifndef _LINUX_KHUGEPAGED_H +#define _LINUX_KHUGEPAGED_H + +#include <linux/sched.h> /* MMF_VM_HUGEPAGE */ + +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +extern int __khugepaged_enter (struct mm_struct *mm); +extern void __khugepaged_exit (struct mm_struct *mm); + +static inline int khugepaged_fork (struct mm_struct *mm,struct mm_struct *oldmm) +{ +if (test_bit (MMF_VM_HUGEPAGE , &oldmm->flags)) +return __khugepaged_enter (mm); +return 0 ; +} + +static inline void khugepaged_exit (struct mm_struct *mm) +{ +if (test_bit (MMF_VM_HUGEPAGE , &mm->flags)) +__khugepaged_exit (mm); +} +#else /* CONFIG_TRANSPARENT_HUGEPAGE */ +static inline int khugepaged_fork (struct mm_struct *mm,struct mm_struct *oldmm) +{ +return 0 ; +} +static inline void khugepaged_exit (struct mm_struct *mm) +{ +} +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ + +#endif /* _LINUX_KHUGEPAGED_H */
include/linux/sched.h +1 -0
@@ -482,6 +482,7 @@ extern int get_dumpable(struct mm_struct#endif /* leave room for more dump flags */ #define MMF_VM_MERGEABLE 16/* KSM may merge identical pages */ +#define MMF_VM_HUGEPAGE 17/* set when VM_HUGEPAGE is set on vma */ #define MMF_INIT_MASK (MMF_DUMPABLE_MASK | MMF_DUMP_FILTER_MASK)
kernel/fork.c +5 -0
@@ -65,6 +65,7 @@#include <linux/perf_event.h> #include <linux/posix-timers.h> #include <linux/user-return-notifier.h> +#include <linux/khugepaged.h> #include <asm/pgtable.h> #include <asm/pgalloc.h>
@@ -306,6 +307,9 @@ static int dup_mmap(struct mm_struct *mm retval =ksm_fork (mm, oldmm);if (retval) goto out; + retval =khugepaged_fork (mm, oldmm); +if (retval) + goto out;for (mpnt = oldmm->mmap; mpnt; mpnt = mpnt->vm_next) {struct file *file;
@@ -515,6 +519,7 @@ void mmput(struct mm_struct *mm)if (atomic_dec_and_test (&mm->mm_users)) {exit_aio (mm);ksm_exit (mm); +khugepaged_exit (mm);/* must run before exit_mmap */ exit_mmap (mm);set_mm_exe_file (mm,NULL );if (!list_empty (&mm->mmlist)) {
mm/huge_memory.c +912 -7
961 lines not on this page · raw message
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 31 of 31] khugepaged
Quoted 7 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Add khugepaged to relocate fragmented pages into hugepages if new hugepages become available. (this is indipendent of the defrag logic that will have to make new hugepages available)
Signed-off-by Andrea Arcangeli<[email protected]>
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 memcg compound
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Teach memcg to charge/uncharge compound pages.
---
mm/memcontrol.c +45 -31
@@ -1401,8 +1401,8 @@ static int __cpuinit memcg_stock_cpu_cal* oom-killer can be invoked. */ static int __mem_cgroup_try_charge (struct mm_struct *mm, -gfp_t gfp_mask,struct mem_cgroup **memcg, -bool oom,struct page *page) +gfp_t gfp_mask,struct mem_cgroup **memcg, +bool oom,struct page *page,int page_size) {struct mem_cgroup *mem, *mem_over_limit;int nr_retries =MEM_CGROUP_RECLAIM_RETRIES ;
@@ -1415,6 +1415,9 @@ static int __mem_cgroup_try_charge(strucreturn 0 ; } +if (PageTransHuge (page)) + csize = page_size; +/* * We always charge the cgroup the mm_struct belongs to. * The mm_struct's mem_cgroup changes on task migration if the
@@ -1439,8 +1442,9 @@ static int __mem_cgroup_try_charge(strucint ret =0 ;unsigned long flags =0 ; -if (consume_stock (mem)) - goto charged; +if (!PageTransHuge (page)) +if (consume_stock (mem)) + goto charged; ret =res_counter_charge (&mem->res, csize, &fail_res);if (likely (!ret)) {
@@ -1460,7 +1464,7 @@ static int __mem_cgroup_try_charge(struc res);/* reduce request size and retry */ -if (csize >PAGE_SIZE ) { +if (csize > page_size) { csize =PAGE_SIZE ;continue ; }
@@ -1491,7 +1495,7 @@ static int __mem_cgroup_try_charge(struc goto nomem; } } -if (csize >PAGE_SIZE ) +if (csize > page_size)refill_stock (mem, csize -PAGE_SIZE ); charged:/*
@@ -1512,12 +1516,12 @@ nomem:* This function is for that and do uncharge, put css's refcnt. * gotten by try_charge(). */ -static void mem_cgroup_cancel_charge (struct mem_cgroup *mem) +static void mem_cgroup_cancel_charge (struct mem_cgroup *mem,int page_size) {if (!mem_cgroup_is_root (mem)) { -res_counter_uncharge (&mem->res,PAGE_SIZE ); +res_counter_uncharge (&mem->res, page_size);if (do_swap_account) -res_counter_uncharge (&mem->memsw,PAGE_SIZE ); +res_counter_uncharge (&mem->memsw, page_size); }css_put (&mem->css); }
@@ -1575,8 +1579,9 @@ struct mem_cgroup *try_get_mem_cgroup_fr*/ static void __mem_cgroup_commit_charge (struct mem_cgroup *mem, -struct page_cgroup *pc, -enum charge_type ctype) +struct page_cgroup *pc, +enum charge_type ctype, +int page_size) {/* try_charge() can return NULL to *memcg, taking care of it. */ if (!mem)
@@ -1585,7 +1590,7 @@ static void __mem_cgroup_commit_charge(slock_page_cgroup (pc);if (unlikely (PageCgroupUsed (pc))) {unlock_page_cgroup (pc); -mem_cgroup_cancel_charge (mem); +mem_cgroup_cancel_charge (mem, page_size);return ; }
@@ -1722,7 +1727,8 @@ static int mem_cgroup_move_parent(struct goto put; parent =mem_cgroup_from_cont (pcg); - ret =__mem_cgroup_try_charge (NULL , gfp_mask, &parent, false, page); + ret =__mem_cgroup_try_charge (NULL , gfp_mask, &parent, false, page, +PAGE_SIZE );if (ret || !parent) goto put_back;
@@ -1730,7 +1736,7 @@ static int mem_cgroup_move_parent(structif (!ret)css_put (&parent->css);/* drop extra refcnt by try_charge() */ else -mem_cgroup_cancel_charge (parent);/* does css_put */ +mem_cgroup_cancel_charge (parent,PAGE_SIZE );/* does css_put */ put_back:putback_lru_page (page); put:
@@ -1752,6 +1758,10 @@ static int mem_cgroup_charge_common(strustruct mem_cgroup *mem;struct page_cgroup *pc;int ret; +int page_size =PAGE_SIZE ; + +if (PageTransHuge (page)) + page_size <<=compound_order (page); pc =lookup_page_cgroup (page);/* can happen at boot */
@@ -1760,11 +1770,12 @@ static int mem_cgroup_charge_common(struprefetchw (pc); mem = memcg; - ret =__mem_cgroup_try_charge (mm, gfp_mask, &mem, true, page); + ret =__mem_cgroup_try_charge (mm, gfp_mask, &mem, true, page, + page_size);if (ret || !mem)return ret; -__mem_cgroup_commit_charge (mem, pc, ctype); +__mem_cgroup_commit_charge (mem, pc, ctype, page_size);return 0 ; }
@@ -1773,8 +1784,6 @@ int mem_cgroup_newpage_charge(struct pag {if (mem_cgroup_disabled ())return 0 ; -if (PageCompound (page)) -return 0 ;/* * If already mapped, we don't have to account. * If page cache, page->mapping has address_space.
@@ -1787,7 +1796,7 @@ int mem_cgroup_newpage_charge(struct pagif (unlikely (!mm)) mm = &init_mm;return mem_cgroup_charge_common (page, mm, gfp_mask, -MEM_CGROUP_CHARGE_TYPE_MAPPED ,NULL ); +MEM_CGROUP_CHARGE_TYPE_MAPPED ,NULL ); } static void
@@ -1880,14 +1889,14 @@ int mem_cgroup_try_charge_swapin(structif (!mem) goto charge_cur_mm; *ptr = mem; - ret =__mem_cgroup_try_charge (NULL , mask, ptr, true, page); + ret =__mem_cgroup_try_charge (NULL , mask, ptr, true, page,PAGE_SIZE );/* drop extra refcnt from tryget */ css_put (&mem->css);return ret; charge_cur_mm:if (unlikely (!mm)) mm = &init_mm; -return __mem_cgroup_try_charge (mm, mask, ptr, true, page); +return __mem_cgroup_try_charge (mm, mask, ptr, true, page,PAGE_SIZE ); } static void
@@ -1903,7 +1912,7 @@ __mem_cgroup_commit_charge_swapin(structcgroup_exclude_rmdir (&ptr->css); pc =lookup_page_cgroup (page);mem_cgroup_lru_del_before_commit_swapcache (page); -__mem_cgroup_commit_charge (ptr, pc, ctype); +__mem_cgroup_commit_charge (ptr, pc, ctype,PAGE_SIZE );mem_cgroup_lru_add_after_commit_swapcache (page);/* * Now swap is on-memory. This means this page may be
@@ -1952,11 +1961,12 @@ void mem_cgroup_cancel_charge_swapin(strreturn ;if (!mem)return ; -mem_cgroup_cancel_charge (mem); +mem_cgroup_cancel_charge (mem,PAGE_SIZE ); }static void -__do_uncharge (struct mem_cgroup *mem,const enum charge_type ctype) +__do_uncharge (struct mem_cgroup *mem,const enum charge_type ctype, +int page_size) {struct memcg_batch_info *batch =NULL ;bool uncharge_memsw = true;
@@ -1989,14 +1999,14 @@ __do_uncharge(struct mem_cgroup *mem, coif (batch->memcg != mem) goto direct_uncharge;/* remember freed charge and uncharge it later */ - batch->bytes +=PAGE_SIZE ; + batch->bytes += page_size;if (uncharge_memsw) - batch->memsw_bytes +=PAGE_SIZE ; + batch->memsw_bytes += page_size;return ; direct_uncharge: -res_counter_uncharge (&mem->res,PAGE_SIZE ); +res_counter_uncharge (&mem->res, page_size);if (uncharge_memsw) -res_counter_uncharge (&mem->memsw,PAGE_SIZE ); +res_counter_uncharge (&mem->memsw, page_size);return ; }
@@ -2009,6 +2019,10 @@ __mem_cgroup_uncharge_common(struct pagestruct page_cgroup *pc;struct mem_cgroup *mem =NULL ;struct mem_cgroup_per_zone *mz; +int page_size =PAGE_SIZE ; + +if (PageTransHuge (page)) + page_size <<=compound_order (page);if (mem_cgroup_disabled ())return NULL ;
@@ -2048,7 +2062,7 @@ __mem_cgroup_uncharge_common(struct page }if (!mem_cgroup_is_root (mem)) -__do_uncharge (mem, ctype); +__do_uncharge (mem, ctype, page_size);if (ctype ==MEM_CGROUP_CHARGE_TYPE_SWAPOUT )mem_cgroup_swap_statistics (mem, true);mem_cgroup_charge_statistics (mem, pc, false);
@@ -2217,7 +2231,7 @@ int mem_cgroup_prepare_migration(structif (mem) { ret =__mem_cgroup_try_charge (NULL ,GFP_KERNEL , &mem, false, - page); + page,PAGE_SIZE );css_put (&mem->css); } *ptr = mem;
@@ -2260,7 +2274,7 @@ void mem_cgroup_end_migration(struct mem* __mem_cgroup_commit_charge() check PCG_USED bit of page_cgroup. * So, double-counting is effectively avoided. */ -__mem_cgroup_commit_charge (mem, pc, ctype); +__mem_cgroup_commit_charge (mem, pc, ctype,PAGE_SIZE );/* * Both of oldpage and newpage are still under lock_page().
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 28 of 31] memcg compound
Quoted 5 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Teach memcg to charge/uncharge compound pages.
Signed-off-by Andrea Arcangeli<[email protected]>
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 madvise(MADV_HUGEPAGE)
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Add madvise MADV_HUGEPAGE to mark regions that are important to be hugepage backed. Return -EINVAL if the vma is not of an anonymous type, or the feature isn't built into the kernel. Never silently return success.
---
include/linux/huge_mm.h +6 -0
@@ -101,6 +101,7 @@ extern int split_huge_page(struct page *#endif extern unsigned long vma_address (struct page *page,struct vm_area_struct *vma); +extern int hugepage_madvise (unsigned long *vm_flags);static inline int PageTransHuge (struct page *page) {VM_BUG_ON (PageTail (page));
@@ -123,6 +124,11 @@ static inline int split_huge_page(struct#define wait_split_huge_page (__anon_vma, __pmd) \ do { } while (0)#define PageTransHuge (page) 0 +static inline int hugepage_madvise (unsigned long *vm_flags) +{ +BUG_ON (0 ); +return 0 ; +}#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ #endif /* _LINUX_HUGE_MM_H */
mm/huge_memory.c +22 -3
@@ -464,9 +464,11 @@ int do_huge_pmd_wp_page(struct mm_structput_page (new_page); new_page =NULL ; } -if (unlikely (!new_page)) -return do_huge_pmd_wp_page_fallback (mm, vma, address, - pmd, orig_pmd, page, haddr); +if (unlikely (!new_page)) { + ret =do_huge_pmd_wp_page_fallback (mm, vma, address, + pmd, orig_pmd, page, haddr); + goto out; + }copy_huge_page (new_page, page, haddr, vma,HPAGE_PMD_NR );__SetPageUptodate (new_page);
@@ -496,6 +498,7 @@ int do_huge_pmd_wp_page(struct mm_struct } out_unlock:spin_unlock (&mm->page_table_lock); +out:return ret; }
@@ -846,3 +849,19 @@ out_unlock: out:return ret; } + +int hugepage_madvise (unsigned long *vm_flags) +{ +/* +* Be somewhat over-protective like KSM for now! +*/ +if (*vm_flags & (VM_HUGEPAGE |VM_SHARED |VM_MAYSHARE | +VM_PFNMAP |VM_IO |VM_DONTEXPAND | +VM_RESERVED |VM_HUGETLB |VM_INSERTPAGE | +VM_MIXEDMAP |VM_SAO )) +return -EINVAL ; + + *vm_flags |=VM_HUGEPAGE ; + +return 0 ; +}
mm/madvise.c +8 -0
@@ -71,6 +71,11 @@ static long madvise_behavior(struct vm_aif (error) goto out;break ; +case MADV_HUGEPAGE : + error =hugepage_madvise (&new_flags); +if (error) + goto out; +break ; }if (new_flags == vma->vm_flags) {
@@ -283,6 +288,9 @@ madvise_behavior_valid(int behavior)case MADV_MERGEABLE :case MADV_UNMERGEABLE :#endif +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +case MADV_HUGEPAGE : +#endif return 1 ;default :
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 26 of 31] madvise(MADV_HUGEPAGE)
Quoted 7 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Add madvise
MADV_HUGEPAGEto mark regions that are important to be hugepage backed. Return-EINVALif the vma is not of an anonymous type, or the feature isn't built into the kernel. Never silently return success.Signed-off-by Andrea Arcangeli<[email protected]>
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 comment reminder in destroy_compound_page
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Warn destroy_compound_page that __split_huge_page_refcount is heavily dependent on its internal behavior.
---
mm/page_alloc.c +1 -0
@@ -311,6 +311,7 @@ void prep_compound_page(struct page *pag } } +/* update __split_huge_page_refcount if you change this function */ static int destroy_compound_page (struct page *page,unsigned long order) {int i;
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 11 of 31] comment reminder in destroy_compound_page
Quoted 6 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Warn
destroy_compound_pagethat__split_huge_page_refcountis heavily dependent on its internal behavior.Signed-off-by Andrea Arcangeli<[email protected]>
Though I guess some of these little patches could be folded together, for easier changeset browsing :)
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 11 of 31] comment reminder in destroy_compound_page
In reply to Andrea ArcangeliQuoted 5 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
Warn
destroy_compound_pagethat__split_huge_page_refcountis heavily dependent on its internal behavior.
Quoted 15 lines
Signed-off-by Andrea Arcangeli <[email protected]>---
mm/page_alloc.c +1
-0@@ -311,6 +311,7 @@ void prep_compound_page(struct page *pag } } +/* update __split_huge_page_refcount if you change this function */ static int destroy_compound_page (struct page *page,unsigned long order) {int i;
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 transparent hugepage vmstat
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Add hugepage stat information to /proc/vmstat and /proc/meminfo.
---
fs/proc/meminfo.c +7 -0
@@ -101,6 +101,9 @@ static int meminfo_proc_show(struct seq_#ifdef CONFIG_MEMORY_FAILURE "HardwareCorrupted: %5lu kB\n"#endif +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +"AnonHugePages: %8lu kB\n" +#endif ,K (i.totalram), K(i.freeram),
@@ -151,6 +154,10 @@ static int meminfo_proc_show(struct seq_#ifdef CONFIG_MEMORY_FAILURE ,atomic_long_read(&mce_bad_pages) << (PAGE_SHIFT - 10)#endif +#ifdef CONFIG_TRANSPARENT_HUGEPAGE + ,K(global_page_state(NR_ANON_TRANSPARENT_HUGEPAGES) * +HPAGE_PMD_NR ) +#endif );hugetlb_report_meminfo (m);
include/linux/mmzone.h +1 -0
@@ -112,6 +112,7 @@ enum zone_stat_item {NUMA_LOCAL ,/* allocation from local node */ NUMA_OTHER ,/* allocation from other node */ #endif +NR_ANON_TRANSPARENT_HUGEPAGES , NR_VM_ZONE_STAT_ITEMS };/*
mm/huge_memory.c +3 -0
@@ -719,6 +719,9 @@ static void __split_huge_page_refcount(sput_page (page_tail); } +__dec_zone_page_state (page,NR_ANON_TRANSPARENT_HUGEPAGES ); +__mod_zone_page_state (zone,NR_ANON_PAGES ,HPAGE_PMD_NR ); +ClearPageCompound (page);compound_unlock (page);spin_unlock_irq (&zone->lru_lock);
mm/rmap.c +16 -4
@@ -687,8 +687,13 @@ void page_add_anon_rmap(struct page *pag struct vm_area_struct *vma, unsigned long address) { int first = atomic_inc_and_test(&page->_mapcount); -if (first) -__inc_zone_page_state (page,NR_ANON_PAGES ); +if (first) { +if (!PageTransHuge (page)) +__inc_zone_page_state (page,NR_ANON_PAGES ); +else +__inc_zone_page_state (page, +NR_ANON_TRANSPARENT_HUGEPAGES ); + }if (unlikely (PageKsm (page)))return ;
@@ -716,7 +721,10 @@ void page_add_new_anon_rmap(struct pageVM_BUG_ON (address < vma->vm_start || address >= vma->vm_end);SetPageSwapBacked (page);atomic_set (&page->_mapcount,0 );/* increment count (starts at -1) */ -__inc_zone_page_state (page,NR_ANON_PAGES ); +if (!PageTransHuge (page)) +__inc_zone_page_state (page,NR_ANON_PAGES ); +else +__inc_zone_page_state (page,NR_ANON_TRANSPARENT_HUGEPAGES );__page_set_anon_rmap (page, vma, address);if (page_evictable (page, vma))lru_cache_add_lru (page,LRU_ACTIVE_ANON );
@@ -763,7 +771,11 @@ void page_remove_rmap(struct page *page) }if (PageAnon (page)) {mem_cgroup_uncharge_page (page); -__dec_zone_page_state (page,NR_ANON_PAGES ); +if (!PageTransHuge (page)) +__dec_zone_page_state (page,NR_ANON_PAGES ); +else +__dec_zone_page_state (page, +NR_ANON_TRANSPARENT_HUGEPAGES ); }else {__dec_zone_page_state (page,NR_FILE_MAPPED );mem_cgroup_update_file_mapped (page,-1 );
mm/vmstat.c +3 -0
@@ -655,6 +655,9 @@ static const char * const vmstat_text[]"numa_local" ,"numa_other" , #endif +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +"nr_anon_transparent_hugepages" , +#endif #ifdef CONFIG_VM_EVENT_COUNTERS "pgpgin",
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 30 of 31] transparent hugepage vmstat
Quoted 7 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Add hugepage stat information to
/proc/vmstatand/proc/meminfo.Signed-off-by Andrea Arcangeli<[email protected]>
mm/rmap.c void page_add_new_anon_rmap(struct page · line 727
Quoted 8 lines
mm/rmap.c +4
-1@@ -716,7 +721,10 @@ void page_add_new_anon_rmap(struct pageVM_BUG_ON (address< vma->vm_start || address>= vma->vm_end);SetPageSwapBacked (page);atomic_set (&page->_mapcount,0 );/* increment count (starts at -1) */ -__inc_zone_page_state (page,NR_ANON_PAGES ); +if (!PageTransHuge (page)) +__inc_zone_page_state (page,NR_ANON_PAGES ); +else +__inc_zone_page_state (page,NR_ANON_TRANSPARENT_HUGEPAGES );
Does this have the potential to unbalance the pageout code, by not counting the hugepages at all? (as opposed to counting a hugepage as 1 page)
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 30 of 31] transparent hugepage vmstat
Quoted 3 lines · Rik van Riel
Does this have the potential to unbalance the pageout code, by not counting the hugepages at all? (as opposed to counting a hugepage as 1 page)
When I checked it looked like this wasn't used by the pageout code.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Rik van Riel
Acked-byRe: [PATCH 30 of 31] transparent hugepage vmstat
Quoted 6 lines · Andrea Arcangeli
Quoted 3 lines · Rik van Riel
Does this have the potential to unbalance the pageout code, by not counting the hugepages at all? (as opposed to counting a hugepage as 1 page)
When I checked it looked like this wasn't used by the pageout code.
You're right. I got confused with the stats that the LRU code maintains. 31 patches is entirely too much in one review sitting :)
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 export maybe_mkwrite
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
huge_memory.c needs it too when it fallbacks in copying hugepages into regular fragmented pages if hugepage allocation fails during COW.
---
include/linux/mm.h +13 -0
@@ -387,6 +387,19 @@ static inline void set_compound_order(st }/* +* Do pte_mkwrite, but only if the vma says VM_WRITE. We do this when +* servicing faults for write access. In the normal case, do always want +* pte_mkwrite. But get_user_pages can cause write faults for mappings +* that do not have writing enabled, when used by access_process_vm. +*/ +static inline pte_t maybe_mkwrite (pte_t pte,struct vm_area_struct *vma) +{ +if (likely (vma->vm_flags &VM_WRITE )) + pte =pte_mkwrite (pte); +return pte; +} + +/* * Multiple processes may "see" the same page. E.g. for untouched * mappings of /dev/null, all processes see the same page full of * zeroes, and text pages of executables and shared libraries have
mm/memory.c +0 -13
@@ -1943,19 +1943,6 @@ static inline int pte_unmap_same(structreturn same; } -/* -* Do pte_mkwrite, but only if the vma says VM_WRITE. We do this when -* servicing faults for write access. In the normal case, do always want -* pte_mkwrite. But get_user_pages can cause write faults for mappings -* that do not have writing enabled, when used by access_process_vm. -*/ -static inline pte_t maybe_mkwrite (pte_t pte,struct vm_area_struct *vma) -{ -if (likely (vma->vm_flags &VM_WRITE )) - pte =pte_mkwrite (pte); -return pte; -} -static inline void cow_user_page (struct page *dst,struct page *src,unsigned long va,struct vm_area_struct *vma) {/*
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 10 of 31] export maybe_mkwrite
Quoted 6 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
huge_memory.cneeds it too when it fallbacks in copying hugepages into regular fragmented pages if hugepage allocation fails during COW.Signed-off-by Andrea Arcangeli<[email protected]>
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 10 of 31] export maybe_mkwrite
In reply to Andrea ArcangeliQuoted 6 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
huge_memory.cneeds it too when it fallbacks in copying hugepages into regular fragmented pages if hugepage allocation fails during COW.Signed-off-by Andrea Arcangeli <[email protected]>
Quoted 49 lines
---
include/linux/mm.h +13
-0@@ -387,6 +387,19 @@ static inline void set_compound_order(st }/* +* Do pte_mkwrite, but only if the vma says VM_WRITE. We do this when +* servicing faults for write access. In the normal case, do always want +* pte_mkwrite. But get_user_pages can cause write faults for mappings +* that do not have writing enabled, when used by access_process_vm. +*/ +static inline pte_t maybe_mkwrite (pte_t pte,struct vm_area_struct *vma) +{ +if (likely (vma->vm_flags &VM_WRITE )) + pte =pte_mkwrite (pte); +return pte; +} + +/* * Multiple processes may "see" the same page. E.g. for untouched * mappings of /dev/null, all processes see the same page full of * zeroes, and text pages of executables and shared libraries have mm/memory.c +0
-13@@ -1943,19 +1943,6 @@ static inline int pte_unmap_same(structreturn same; } -/* -* Do pte_mkwrite, but only if the vma says VM_WRITE. We do this when -* servicing faults for write access. In the normal case, do always want -* pte_mkwrite. But get_user_pages can cause write faults for mappings -* that do not have writing enabled, when used by access_process_vm. -*/ -static inline pte_t maybe_mkwrite (pte_t pte,struct vm_area_struct *vma) -{ -if (likely (vma->vm_flags &VM_WRITE )) - pte =pte_mkwrite (pte); -return pte; -} -static inline void cow_user_page (struct page *dst,struct page *src,unsigned long va,struct vm_area_struct *vma) {/*
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 memcg huge memory
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Add memcg charge/uncharge to hugepage faults in huge_memory.c.
---
mm/huge_memory.c +25 -5
@@ -212,6 +212,7 @@ static int __do_huge_pmd_anonymous_page(VM_BUG_ON (!PageCompound (page)); pgtable =pte_alloc_one (mm, address);if (unlikely (!pgtable)) { +mem_cgroup_uncharge_page (page);put_page (page);return VM_FAULT_OOM ; }
@@ -229,6 +230,7 @@ static int __do_huge_pmd_anonymous_page(spin_lock (&mm->page_table_lock);if (unlikely (!pmd_none (*pmd))) {spin_unlock (&mm->page_table_lock); +mem_cgroup_uncharge_page (page);put_page (page);pte_free (mm, pgtable); }else {
@@ -266,6 +268,10 @@ int do_huge_pmd_anonymous_page(struct mm page =alloc_hugepage (transparent_hugepage_defrag (vma));if (unlikely (!page)) goto out; +if (unlikely (mem_cgroup_newpage_charge (page, mm,GFP_KERNEL ))) { +put_page (page); + goto out; + }return __do_huge_pmd_anonymous_page (mm, vma, address, pmd, page, haddr);
@@ -366,9 +372,15 @@ static int do_huge_pmd_wp_page_fallback(for (i =0 ; i <HPAGE_PMD_NR ; i++) { pages[i] =alloc_page_vma (GFP_HIGHUSER_MOVABLE , vma, address); -if (unlikely (!pages[i])) { -while (--i >=0 ) +if (unlikely (!pages[i] || +mem_cgroup_newpage_charge (pages[i], mm, +GFP_KERNEL ))) { +if (pages[i])put_page (pages[i]); +while (--i >=0 ) { +mem_cgroup_uncharge_page (pages[i]); +put_page (pages[i]); + }kfree (pages); ret |=VM_FAULT_OOM ; goto out;
@@ -427,8 +439,10 @@ out: out_free_pages:spin_unlock (&mm->page_table_lock); -for (i =0 ; i <HPAGE_PMD_NR ; i++) +for (i =0 ; i <HPAGE_PMD_NR ; i++) { +mem_cgroup_uncharge_page (pages[i]);put_page (pages[i]); + }kfree (pages); goto out; }
@@ -470,6 +484,11 @@ int do_huge_pmd_wp_page(struct mm_struct goto out; } +if (unlikely (mem_cgroup_newpage_charge (new_page, mm,GFP_KERNEL ))) { +put_page (new_page); + ret |=VM_FAULT_OOM ; + goto out; + }copy_huge_page (new_page, page, haddr, vma,HPAGE_PMD_NR );__SetPageUptodate (new_page);
@@ -481,9 +500,10 @@ int do_huge_pmd_wp_page(struct mm_structsmp_wmb ();spin_lock (&mm->page_table_lock); -if (unlikely (!pmd_same (*pmd, orig_pmd))) +if (unlikely (!pmd_same (*pmd, orig_pmd))) { +mem_cgroup_uncharge_page (new_page);put_page (new_page); -else { + }else {pmd_t entry; entry =mk_pmd (new_page, vma->vm_page_prot); entry =maybe_pmd_mkwrite (pmd_mkdirty (entry), vma);
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 29 of 31] memcg huge memory
Quoted 5 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Add memcg charge/uncharge to hugepage faults in
huge_memory.c.Signed-off-by Andrea Arcangeli<[email protected]>
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 clear compound mapping
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Clear compound mapping for anonymous compound pages like it already happens for regular anonymous pages.
---
mm/page_alloc.c +2 -0
@@ -584,6 +584,8 @@ static void __free_pages_ok(struct pagekmemcheck_free_shadow (page, order); +if (PageAnon (page)) + page->mapping =NULL ;for (i =0 ; i < (1 << order) ; ++i) bad +=free_pages_check (page + i);if (bad)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 06 of 31] clear compound mapping
Quoted 6 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Clear compound mapping for anonymous compound pages like it already happens for regular anonymous pages.
Signed-off-by Andrea Arcangeli<[email protected]>
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 06 of 31] clear compound mapping
In reply to Andrea ArcangeliQuoted 6 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
Clear compound mapping for anonymous compound pages like it already happens for regular anonymous pages.
Signed-off-by Andrea Arcangeli <[email protected]>
Quoted 15 lines
---
mm/page_alloc.c +2
-0@@ -584,6 +584,8 @@ static void __free_pages_ok(struct pagekmemcheck_free_shadow (page, order); +if (PageAnon (page)) + page->mapping =NULL ;for (i =0 ; i < (1 << order) ; ++i) bad +=free_pages_check (page + i);if (bad)
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 update futex compound knowledge
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Futex code is smarter than most other gup_fast O_DIRECT code and knows about the compound internals. However now doing a put_page(head_page) will not release the pin on the tail page taken by gup-fast, leading to all sort of refcounting bugchecks. Getting a stable head_page is a little tricky.
---
kernel/futex.c +33 -9
@@ -218,7 +218,7 @@ get_futex_key(u32 __user *uaddr, int fsh {unsigned long address = (unsigned long )uaddr;struct mm_struct *mm = current->mm; -struct page *page; +struct page *page, *page_head;int err;/*
@@ -250,10 +250,32 @@ again:if (err <0 )return err; - page =compound_head (page); -lock_page (page); -if (!page->mapping) { -unlock_page (page); + page_head = page; +if (unlikely (PageTail (page))) { +put_page (page); +/* serialize against __split_huge_page_splitting() */ +local_irq_disable (); +if (likely (__get_user_pages_fast (address,1 ,1 , &page) ==1 )) { + page_head =compound_head (page); +local_irq_enable (); + }else { +local_irq_enable (); + goto again; + } + } + +lock_page (page_head); +if (unlikely (page_head != page)) { +compound_lock (page_head); +if (unlikely (!PageTail (page))) { +compound_unlock (page_head); +unlock_page (page_head); +put_page (page); + goto again; + } + } +if (!page_head->mapping) { +unlock_page (page_head);put_page (page); goto again; }
@@ -265,19 +287,21 @@ again:* it's a read-only handle, it's expected that futexes attach to * the object not the particular process. */ -if (PageAnon (page)) { +if (PageAnon (page_head)) { key->both.offset |=FUT_OFF_MMSHARED ;/* ref taken on mm */ key->private.mm = mm; key->private.address = address; }else { key->both.offset |=FUT_OFF_INODE ;/* inode-based key */ - key->shared.inode = page->mapping->host; - key->shared.pgoff = page->index; + key->shared.inode = page_head->mapping->host; + key->shared.pgoff = page_head->index; }get_futex_key_refs (key); -unlock_page (page); +if (unlikely (PageTail (page))) +compound_unlock (page_head); +unlock_page (page_head);put_page (page);return 0 ; }
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 04 of 31] update futex compound knowledge
Quoted 31 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Futex code is smarter than most other
gup_fastO_DIRECTcode and knows about the compound internals. However now doing aput_page(head_page)will not release the pin on the tail page taken by gup-fast, leading to all sort of refcounting bugchecks. Getting a stablehead_pageis a little tricky.Signed-off-by Andrea Arcangeli<[email protected]>---
kernel/futex.c +2
-5@@ -218,7 +218,7 @@ get_futex_key(u32 __user *uaddr, int fsh {unsigned long address = (unsigned long )uaddr;struct mm_struct *mm = current->mm; -struct page *page; +struct page *page, *page_head;int err;/* @@ -250,10 +250,32 @@ again:if (err<0 )return err; - page =compound_head (page); -lock_page (page); -if (!page->mapping) { -unlock_page (page); + page_head = page;
...
kernel/futex.c again: · line 268
Quoted 1 line
kernel/futex.c +1
-0+if (unlikely (page_head != page)) {
Should the line above be "page_head = compound_head(page);" or am I missing something?
If I am missing something, the changelog message could be a little more verbose :)
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 04 of 31] update futex compound knowledge
Quoted 35 lines · Rik van Riel
Quoted 31 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Futex code is smarter than most other
gup_fastO_DIRECTcode and knows about the compound internals. However now doing aput_page(head_page)will not release the pin on the tail page taken by gup-fast, leading to all sort of refcounting bugchecks. Getting a stablehead_pageis a little tricky.Signed-off-by Andrea Arcangeli<[email protected]>---
kernel/futex.c +2
-5@@ -218,7 +218,7 @@ get_futex_key(u32 __user *uaddr, int fsh {unsigned long address = (unsigned long )uaddr;struct mm_struct *mm = current->mm; -struct page *page; +struct page *page, *page_head;int err;/* @@ -250,10 +250,32 @@ again:if (err<0 )return err; - page =compound_head (page); -lock_page (page); -if (!page->mapping) { -unlock_page (page); + page_head = page;...
Quoted 4 lines
kernel/futex.c again: · line 268
Quoted 1 line
kernel/futex.c +1
-0+if (unlikely (page_head != page)) {Should the line above be "
page_head=compound_head(page);" or am I missing something?
page_head = page is there because if this is not a tail page it's also the page_head. Only in case this is a tail page, compound_head is called, otherwise it's guaranteed unnecessary. And if it's a tail page compound_head has to run atomically inside irq disabled section __get_user_pages_fast before returning. Otherwise ->first_page won't be a stable pointer.
Quoted 2 lines
If I am missing something, the changelog message could be a little more verbose :)
Ok will add the above comments ;)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Rik van Riel
Acked-byRe: [PATCH 04 of 31] update futex compound knowledge
Quoted 11 lines · Andrea Arcangeli
Quoted 2 lines · Rik van Riel
Should the line above be "
page_head=compound_head(page);" or am I missing something?
page_head= page is there because if this is not a tail page it's also thepage_head. Only in case this is a tail page,compound_headis called, otherwise it's guaranteed unnecessary. And if it's a tail pagecompound_headhas to run atomically inside irq disabled section__get_user_pages_fastbefore returning. Otherwise ->first_page won't be a stable pointer.
Ahh, I see it now.
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 04 of 31] update futex compound knowledge
In reply to Andrea ArcangeliQuoted 26 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
Futex code is smarter than most other
gup_fastO_DIRECTcode and knows about the compound internals. However now doing aput_page(head_page)will not release the pin on the tail page taken by gup-fast, leading to all sort of refcounting bugchecks. Getting a stablehead_pageis a little tricky.Signed-off-by Andrea Arcangeli <[email protected]>---
kernel/futex.c +1
-1@@ -218,7 +218,7 @@ get_futex_key(u32 __user *uaddr, int fsh {unsigned long address = (unsigned long )uaddr;struct mm_struct *mm = current->mm; -struct page *page; +struct page *page, *page_head;int err;/* @@ -250,10 +250,32 @@ again:if (err <0 )return err;
kernel/futex.c again: · line 258
Quoted 10 lines
kernel/futex.c +6
-4- page =compound_head (page); -lock_page (page); -if (!page->mapping) { -unlock_page (page); + page_head = page; +if (unlikely (PageTail (page))) { +put_page (page); +/* serialize against __split_huge_page_splitting() */ +local_irq_disable (); +if (likely (__get_user_pages_fast (address,1 ,1 , &page) ==1 )) {
I'm not fully getting from the changelog why the second round through __get_user_pages_fast() is necessary or why the write parameter is unconditionally 1.
Is the second round necessary just so compound_head() is called with interrupts disabled? Is that sufficient?
Quoted 50 lines
kernel/futex.c +26
-4+ page_head =compound_head (page); +local_irq_enable (); + }else { +local_irq_enable (); + goto again; + } + } + +lock_page (page_head); +if (unlikely (page_head != page)) { +compound_lock (page_head); +if (unlikely (!PageTail (page))) { +compound_unlock (page_head); +unlock_page (page_head); +put_page (page); + goto again; + } + } +if (!page_head->mapping) { +unlock_page (page_head);put_page (page); goto again; }@@ -265,19 +287,21 @@ again:* it's a read-only handle, it's expected that futexes attach to * the object not the particular process. */ -if (PageAnon (page)) { +if (PageAnon (page_head)) { key->both.offset |=FUT_OFF_MMSHARED ;/* ref taken on mm */ key->private.mm = mm; key->private.address = address; }else { key->both.offset |=FUT_OFF_INODE ;/* inode-based key */ - key->shared.inode = page->mapping->host; - key->shared.pgoff = page->index; + key->shared.inode = page_head->mapping->host; + key->shared.pgoff = page_head->index; }get_futex_key_refs (key); -unlock_page (page); +if (unlikely (PageTail (page))) +compound_unlock (page_head); +unlock_page (page_head);put_page (page);return 0 ; }
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 04 of 31] update futex compound knowledge
Quoted 3 lines · Mel Gorman
I'm not fully getting from the changelog why the second round through
__get_user_pages_fast()is necessary or why the write parameter is unconditionally 1.
The write parameter is unconditionally to 1 because the first gup_fast already existing had it unconditionally set to 1, it's not relevant with this change.
Quoted 2 lines
Is the second round necessary just so
compound_head()is called with interrupts disabled? Is that sufficient?
Correct. It's necessary and sufficient, because if it returns == 1, it means the huge pmd is established and cannot go away from under us. pmdp_splitting_flush_notify in __split_huge_page_splitting will have to wait for local_irq_enable before the IPI delivery can return. This means __split_huge_page_refcount can't be running from under us, and in turn when we run compound_head(page) we're not reading a dangling pointer from tailpage->first_page. Then after we get to stable head page, we are always safe to call compound_lock and after taking the compound lock on head page we can finally re-check if the page returned by gup-fast is still a tail page. in which case we're set and we didn't need to split the hugepage in order to take a futex on it.
I'll add above to changelog.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 04 of 31] update futex compound knowledge
Quoted 9 lines · Andrea Arcangeli
Quoted 3 lines · Mel Gorman
I'm not fully getting from the changelog why the second round through
__get_user_pages_fast()is necessary or why the write parameter is unconditionally 1.The write parameter is unconditionally to 1 because the first
gup_fastalready existing had it unconditionally set to 1, it's not relevant with this change.
hmm, really? I was seeing rw == VERIFY_WRITE rather than an unconditional. I'll double check the kernel version I'm reading against when I read the next review.
Quoted 16 lines
Quoted 2 lines
Is the second round necessary just so
compound_head()is called with interrupts disabled? Is that sufficient?Correct. It's necessary and sufficient, because if it returns == 1, it means the huge pmd is established and cannot go away from under us.
pmdp_splitting_flush_notifyin__split_huge_page_splittingwill have to wait forlocal_irq_enablebefore the IPI delivery can return. This means__split_huge_page_refcountcan't be running from under us, and in turn when we runcompound_head(page)we're not reading a dangling pointer fromtailpage->first_page. Then after we get to stable head page, we are always safe to callcompound_lockand after taking the compound lock on head page we can finally re-check if the page returned by gup-fast is still a tail page. in which case we're set and we didn't need to split the hugepage in order to take a futex on it.
Quoted 2 lines
I'll add above to changelog.
Do please. That explanation helps a lot.
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 04 of 31] update futex compound knowledge
Quoted 6 lines · Mel Gorman
Quoted 5 lines · Andrea Arcangeli
Quoted 3 lines · Mel Gorman
I'm not fully getting from the changelog why the second round through
__get_user_pages_fast()is necessary or why the write parameter is unconditionally 1.
Quoted 8 lines
Quoted 4 lines
The write parameter is unconditionally to 1 because the first
gup_fastalready existing had it unconditionally set to 1, it's not relevant with this change.hmm, really? I was seeing rw ==
VERIFY_WRITErather than an unconditional. I'll double check the kernel version I'm reading against when I read the next review.
No problem ;) and now I get why asked it, in my current version (last pull) the code is:
again:
err = get_user_pages_fast(address, 1, 1, &page);
Clearly if the above would have been rw == VERIFY_WRITE I would have not used 1 in the __ irq disabled callout.
Quoted 1 line
Do please. That explanation helps a lot.
Glad it helps despite my broken english eheh, already included in #8 submit ;)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 split_huge_page_mm/vma
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
split_huge_page_mm/vma compat code. Each one of those would need to be expanded to hundred of lines of complex code without a fully reliable split_huge_page_mm/vma functionality.
---
arch/x86/kernel/vm86_32.c +1 -0
@@ -179,6 +179,7 @@ static void mark_screen_rdonly(struct mmif (pud_none_or_clear_bad (pud)) goto out; pmd =pmd_offset (pud,0xA0000 ); +split_huge_page_mm (mm,0xA0000 , pmd);if (pmd_none_or_clear_bad (pmd)) goto out; pte =pte_offset_map_lock (mm, pmd,0xA0000 , &ptl);
mm/mempolicy.c +1 -0
@@ -446,6 +446,7 @@ static inline int check_pmd_range(struct pmd =pmd_offset (pud, addr); do { next = pmd_addr_end(addr, end); + split_huge_page_vma(vma, pmd); if (pmd_none_or_clear_bad(pmd)) continue; if (check_pte_range(vma, pmd, addr, next, nodes,
mm/mincore.c +1 -0
@@ -132,6 +132,7 @@ static long do_mincore(unsigned long addif (pud_none_or_clear_bad (pud)) goto none_mapped; pmd =pmd_offset (pud, addr); +split_huge_page_vma (vma, pmd);if (pmd_none_or_clear_bad (pmd)) goto none_mapped;
mm/mprotect.c +1 -0
@@ -89,6 +89,7 @@ static inline void change_pmd_range(stru pmd =pmd_offset (pud, addr); do { next = pmd_addr_end(addr, end); + split_huge_page_mm(mm, addr, pmd); if (pmd_none_or_clear_bad(pmd)) continue; change_pte_range(mm, pmd, addr, next, newprot, dirty_accountable);
mm/mremap.c +1 -0
@@ -42,6 +42,7 @@ static pmd_t *get_old_pmd(struct mm_strureturn NULL ; pmd =pmd_offset (pud, addr); +split_huge_page_mm (mm, addr, pmd);if (pmd_none_or_clear_bad (pmd))return NULL ;
mm/pagewalk.c +1 -0
@@ -34,6 +34,7 @@ static int walk_pmd_range(pud_t *pud, un pmd =pmd_offset (pud, addr); do { next = pmd_addr_end(addr, end); + split_huge_page_mm(walk->mm, addr, pmd); if (pmd_none_or_clear_bad(pmd)) { if (walk->pte_hole) err = walk->pte_hole(addr, next, walk);
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 21 of 31] split_huge_page_mm/vma
Quoted 69 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
split_huge_page_mm/vma compat code. Each one of those would need to be expanded to hundred of lines of complex code without a fully reliable split_huge_page_mm/vma functionality.
Signed-off-by Andrea Arcangeli <[email protected]>---
arch/x86/kernel/vm86_32.c +1
-0@@ -179,6 +179,7 @@ static void mark_screen_rdonly(struct mmif (pud_none_or_clear_bad (pud)) goto out; pmd =pmd_offset (pud,0xA0000 ); +split_huge_page_mm (mm,0xA0000 , pmd);if (pmd_none_or_clear_bad (pmd)) goto out; pte =pte_offset_map_lock (mm, pmd,0xA0000 , &ptl);mm/mempolicy.c +1
-0@@ -446,6 +446,7 @@ static inline int check_pmd_range(struct pmd =pmd_offset (pud, addr); do { next = pmd_addr_end(addr, end); + split_huge_page_vma(vma, pmd); if (pmd_none_or_clear_bad(pmd)) continue; if (check_pte_range(vma, pmd, addr, next, nodes,mm/mincore.c +1
-0@@ -132,6 +132,7 @@ static long do_mincore(unsigned long addif (pud_none_or_clear_bad (pud)) goto none_mapped; pmd =pmd_offset (pud, addr); +split_huge_page_vma (vma, pmd);if (pmd_none_or_clear_bad (pmd)) goto none_mapped;mm/mprotect.c +1
-0@@ -89,6 +89,7 @@ static inline void change_pmd_range(stru pmd =pmd_offset (pud, addr); do { next = pmd_addr_end(addr, end); + split_huge_page_mm(mm, addr, pmd); if (pmd_none_or_clear_bad(pmd)) continue; change_pte_range(mm, pmd, addr, next, newprot, dirty_accountable);mm/mremap.c +1
-0@@ -42,6 +42,7 @@ static pmd_t *get_old_pmd(struct mm_strureturn NULL ; pmd =pmd_offset (pud, addr); +split_huge_page_mm (mm, addr, pmd);if (pmd_none_or_clear_bad (pmd))return NULL ;
mm/pagewalk.c static int walk_pmd_range(pud_t *pud, un · line 40
Quoted 7 lines
mm/pagewalk.c +1
-0@@ -34,6 +34,7 @@ static int walk_pmd_range(pud_t *pud, un pmd =pmd_offset (pud, addr); do { next = pmd_addr_end(addr, end); + split_huge_page_mm(walk->mm, addr, pmd); if (pmd_none_or_clear_bad(pmd)) { if (walk->pte_hole) err = walk->pte_hole(addr, next, walk);
I guess this is the part that breaks huge pages when smaps is read. That is a bit of a snag as a normal user could cause a lot of churn by reading those files a lot.
In the event that gets fixed up, it's worth considering what KernelPageSize:
and MMUPageSize: should be printing in smaps for regions of memory backed by a mix of base and huge pages.
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 21 of 31] split_huge_page_mm/vma
Quoted 3 lines · Mel Gorman
I guess this is the part that breaks huge pages when smaps is read. That is a bit of a snag as a normal user could cause a lot of churn by reading those files a lot.
yep, this is the highest priority split_huge_page to remove, along with fixing lru stats. mprotect and mremap are much lower prio. I think I mentioned the removal of split_huge_page from smaps in earlier emails too.
Quoted 3 lines
In the event that gets fixed up, it's worth considering what KernelPageSize:
and MMUPageSize: should be printing in smaps for regions of memory backed by a mix of base and huge pages.
Suggestions and patches welcome. I just deferred it for later and no app on my system seems to cat those files but it's definitely something to fix or it's just spurious overhead given to khugepaged...
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Mel Gorman
Acked-byRe: [PATCH 21 of 31] split_huge_page_mm/vma
Quoted 10 lines · Andrea Arcangeli
Quoted 3 lines · Mel Gorman
I guess this is the part that breaks huge pages when smaps is read. That is a bit of a snag as a normal user could cause a lot of churn by reading those files a lot.
yep, this is the highest priority
split_huge_pageto remove, along with fixing lru stats. mprotect and mremap are much lower prio. I think I mentioned the removal ofsplit_huge_pagefrom smaps in earlier emails too.
Probably. It rings a bell for sure.
Quoted 8 lines
Quoted 3 lines
In the event that gets fixed up, it's worth considering what KernelPageSize:
and MMUPageSize: should be printing in smaps for regions of memory backed by a mix of base and huge pages.Suggestions and patches welcome. I just deferred it for later and no app on my system seems to cat those files but it's definitely something to fix or it's just spurious overhead given to khugepaged...
I'd be very surprised if there are apps that cat those files because they are expensive to read from a kernel perspective and not the cheapest to parse either. It's intended for monitoring tools that report on hugepage usage on a per-application basis.
Not a high priority and I'll give it some thought. Just mentioning it in case I forgot to bring it up later.
Otherwise;
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 21 of 31] split_huge_page_mm/vma
In reply to Andrea ArcangeliQuoted 7 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
split_huge_page_mm/vma compat code. Each one of those would need to be expanded to hundred of lines of complex code without a fully reliable split_huge_page_mm/vma functionality.
Signed-off-by Andrea Arcangeli<[email protected]>
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 add native_set_pmd_at
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Used by paravirt and not paravirt set_pmd_at.
---
arch/x86/include/asm/pgtable.h +6 -0
@@ -528,6 +528,12 @@ static inline void native_set_pte_at(strnative_set_pte (ptep, pte); } +static inline void native_set_pmd_at (struct mm_struct *mm,unsigned long addr, +pmd_t *pmdp ,pmd_t pmd) +{ +native_set_pmd (pmdp, pmd); +} +#ifndef CONFIG_PARAVIRT /* * Rules for using pte_update - it must be called after any PTE update which
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 07 of 31] add native_set_pmd_at
Quoted 5 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Used by paravirt and not paravirt
set_pmd_at.Signed-off-by Andrea Arcangeli<[email protected]>
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 07 of 31] add native_set_pmd_at
In reply to Andrea ArcangeliQuoted 5 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
Used by paravirt and not paravirt
set_pmd_at.Signed-off-by Andrea Arcangeli <[email protected]>
Quoted 19 lines
---
arch/x86/include/asm/pgtable.h +6
-0@@ -528,6 +528,12 @@ static inline void native_set_pte_at(strnative_set_pte (ptep, pte); } +static inline void native_set_pmd_at (struct mm_struct *mm,unsigned long addr, +pmd_t *pmdp ,pmd_t pmd) +{ +native_set_pmd (pmdp, pmd); +} +#ifndef CONFIG_PARAVIRT /* * Rules for using pte_update - it must be called after any PTE update which
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 compound_lock
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Add a new compound_lock() needed to serialize put_page against __split_huge_page_refcount().
---
include/linux/mm.h +11 -0
@@ -12,6 +12,7 @@#include <linux/prio_tree.h> #include <linux/debug_locks.h> #include <linux/mm_types.h> +#include <linux/bit_spinlock.h> struct mempolicy ;struct anon_vma ;
@@ -294,6 +295,16 @@ static inline int is_vmalloc_or_module_a }#endif +static inline void compound_lock (struct page *page) +{ +bit_spin_lock (PG_compound_lock, &page->flags); +} + +static inline void compound_unlock (struct page *page) +{ +bit_spin_unlock (PG_compound_lock, &page->flags); +} +static inline struct page *compound_head (struct page *page) {if (unlikely (PageTail (page)))
include/linux/page-flags.h +1 -0
@@ -108,6 +108,7 @@ enum pageflags {#ifdef CONFIG_MEMORY_FAILURE PG_hwpoison,/* hardware poisoned page. Don't touch */ #endif + PG_compound_lock, __NR_PAGEFLAGS,/* Filesystems */
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 02 of 31] compound_lock
Quoted 11 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Add a new
compound_lock()needed to serializeput_pageagainst__split_huge_page_refcount().Signed-off-by Andrea Arcangeli<[email protected]>
include/linux/page-flags.h enum pageflags { · line 111
Quoted 4 lines
include/linux/page-flags.h +1
-0@@ -108,6 +108,7 @@ enum pageflags {#ifdef CONFIG_MEMORY_FAILURE PG_hwpoison,/* hardware poisoned page. Don't touch */ #endif + PG_compound_lock,
Maybe this should be under an #ifdef so it does not take up a bit flag on 32 bit systems where it isn't compiled?
Other than that,
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 02 of 31] compound_lock
Hi Rik,
Quoted 8 lines · Rik van Riel
Quoted 6 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Add a new
compound_lock()needed to serializeput_pageagainst__split_huge_page_refcount().Signed-off-by Andrea Arcangeli<[email protected]>
Quoted 11 lines
include/linux/page-flags.h enum pageflags { · line 111
Quoted 8 lines
include/linux/page-flags.h +1
-0@@ -108,6 +108,7 @@ enum pageflags {#ifdef CONFIG_MEMORY_FAILURE PG_hwpoison,/* hardware poisoned page. Don't touch */ #endif + PG_compound_lock,Maybe this should be under an #ifdef so it does not take up a bit flag on 32 bit systems where it isn't compiled?
yes, on 32bit in fact it won't fit anymore... I already updated this on #7 compound_get_put:
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
PG_compound_lock,
+#endif
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
bit_spin_lock(PG_compound_lock, &page->flags);
+#endif
}
static inline void compound_unlock(struct page *page) {
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
bit_spin_unlock(PG_compound_lock, &page->flags);
+#endif
Maybe I should have folded those changes into compound_lock patch instead of compound_get_put, end result is the same...
I already eliminated the atomoc op at compile time when the feature is disabled and for archs not using the feature, but I'm still considering if to return to the entire old get/put_page code when feature is disabled at compile time or at runtime for hugetlbfs only... I think removing the atomic op is the most important but it's done at compile time not at runtime right now.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 02 of 31] compound_lock
In reply to Rik van RielQuoted 2 lines · Rik van Riel
Maybe this should be under an #ifdef so it does not take up a bit flag on 32 bit systems where it isn't compiled?
I have made the same comment on earlier versions.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 02 of 31] compound_lock
Quoted 6 lines · Christoph Lameter
Quoted 2 lines · Rik van Riel
Maybe this should be under an #ifdef so it does not take up a bit flag on 32 bit systems where it isn't compiled?
I have made the same comment on earlier versions.
Maybe I misunderstood your comment but note that I answered to that comment of yours with "So I can optimize away that PG_compound_lock with CONFIG_TRANSPARENT_HUGEPAGE=n if you want.". This is exactly what I did now, and you didn't answer to my reply, so I had no way to be sure that's the only thing you meant with TRANSP_HUGE, in which case we would have been in full agreement already.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 02 of 31] compound_lock
In reply to Andrea ArcangeliQuoted 6 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
Add a new
compound_lock()needed to serializeput_pageagainst__split_huge_page_refcount().Signed-off-by Andrea Arcangeli <[email protected]>
Other than the 32-bit aspects which have already been discussed.
Quoted 42 lines
---
include/linux/mm.h +11
-0@@ -12,6 +12,7 @@#include <linux/prio_tree.h> #include <linux/debug_locks.h> #include <linux/mm_types.h> +#include <linux/bit_spinlock.h> struct mempolicy ;struct anon_vma ;@@ -294,6 +295,16 @@ static inline int is_vmalloc_or_module_a }#endif +static inline void compound_lock (struct page *page) +{ +bit_spin_lock (PG_compound_lock, &page->flags); +} + +static inline void compound_unlock (struct page *page) +{ +bit_spin_unlock (PG_compound_lock, &page->flags); +} +static inline struct page *compound_head (struct page *page) {if (unlikely (PageTail (page)))include/linux/page-flags.h +1
-0@@ -108,6 +108,7 @@ enum pageflags {#ifdef CONFIG_MEMORY_FAILURE PG_hwpoison,/* hardware poisoned page. Don't touch */ #endif + PG_compound_lock, __NR_PAGEFLAGS,/* Filesystems */
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 transparent hugepage core
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Lately I've been working to make KVM use hugepages transparently without the usual restrictions of hugetlbfs. Some of the restrictions I'd like to see removed:
1) hugepages have to be swappable or the guest physical memory remains locked in RAM and can't be paged out to swap
2) if a hugepage allocation fails, regular pages should be allocated instead and mixed in the same vma without any failure and without userland noticing
3) if some task quits and more hugepages become available in the buddy, guest physical memory backed by regular pages should be relocated on hugepages automatically in regions under madvise(MADV_HUGEPAGE) (ideally event driven by waking up the kernel deamon if the order=HPAGE_PMD_SHIFT-PAGE_SHIFT list becomes not null)
4) avoidance of reservation and maximization of use of hugepages whenever possible. Reservation (needed to avoid runtime fatal faliures) may be ok for 1 machine with 1 database with 1 database cache with 1 database cache size known at boot time. It's definitely not feasible with a virtualization hypervisor usage like RHEV-H that runs an unknown number of virtual machines with an unknown size of each virtual machine with an unknown amount of pagecache that could be potentially useful in the host for guest not using O_DIRECT (aka cache=off).
hugepages in the virtualization hypervisor (and also in the guest!) are much more important than in a regular host not using virtualization, becasue with NPT/EPT they decrease the tlb-miss cacheline accesses from 24 to 19 in case only the hypervisor uses transparent hugepages, and they decrease the tlb-miss cacheline accesses from 19 to 15 in case both the linux hypervisor and the linux guest both uses this patch (though the guest will limit the addition speedup to anonymous regions only for now...). Even more important is that the tlb miss handler is much slower on a NPT/EPT guest than for a regular shadow paging or no-virtualization scenario. So maximizing the amount of virtual memory cached by the TLB pays off significantly more with NPT/EPT than without (even if there would be no significant speedup in the tlb-miss runtime).
The first (and more tedious) part of this work requires allowing the VM to handle anonymous hugepages mixed with regular pages transparently on regular anonymous vmas. This is what this patch tries to achieve in the least intrusive possible way. We want hugepages and hugetlb to be used in a way so that all applications can benefit without changes (as usual we leverage the KVM virtualization design: by improving the Linux VM at large, KVM gets the performance boost too).
The most important design choice is: always fallback to 4k allocation if the hugepage allocation fails! This is the _very_ opposite of some large pagecache patches that failed with -EIO back then if a 64k (or similar) allocation failed...
Second important decision (to reduce the impact of the feature on the existing pagetable handling code) is that at any time we can split an hugepage into 512 regular pages and it has to be done with an operation that can't fail. This way the reliability of the swapping isn't decreased (no need to allocate memory when we are short on memory to swap) and it's trivial to plug a split_huge_page* one-liner where needed without polluting the VM. Over time we can teach mprotect, mremap and friends to handle pmd_trans_huge natively without calling split_huge_page*. The fact it can't fail isn't just for swap:
if split_huge_page would return -ENOMEM (instead of the current void) we'd need to rollback the mprotect from the middle of it (ideally including undoing the split_vma) which would be a big change and in the very wrong direction (it'd likely be simpler not to call split_huge_page at all and to teach mprotect and friends to handle hugepages instead of rolling them back from the middle). In short the very value of split_huge_page is that it can't fail.
The collapsing and madvise(MADV_HUGEPAGE) part will remain separated and incremental and it'll just be an "harmless" addition later if this initial part is agreed upon. It also should be noted that locking-wise replacing regular pages with hugepages is going to be very easy if compared to what I'm doing below in split_huge_page, as it will only happen when page_count(page) matches page_mapcount(page) if we can take the PG_lock and mmap_sem in write mode. collapse_huge_page will be a "best effort" that (unlike split_huge_page) can fail at the minimal sign of trouble and we can try again later. collapse_huge_page will be similar to how KSM works and the madvise(MADV_HUGEPAGE) will work similar to madvise(MADV_MERGEABLE).
The default I like is that transparent hugepages are used at page fault time. This can be changed with /sys/kernel/mm/transparent_hugepage/enabled. The control knob can be set to three values "always", "madvise", "never" which mean respectively that hugepages are always used, or only inside madvise(MADV_HUGEPAGE) regions, or never used. /sys/kernel/mm/transparent_hugepage/defrag instead controls if the hugepage allocation should defrag memory aggressively "always", only inside "madvise" regions, or "never".
The pmd_trans_splitting/pmd_trans_huge locking is very solid. The put_page (from get_user_page users that can't use mmu notifier like O_DIRECT) that runs against a __split_huge_page_refcount instead was a pain to serialize in a way that would result always in a coherent page count for both tail and head. I think my locking solution with a compound_lock taken only after the page_first is valid and is still a PageHead should be safe but it surely needs review from SMP race point of view. In short there is no current existing way to serialize the O_DIRECT final put_page against split_huge_page_refcount so I had to invent a new one (O_DIRECT loses knowledge on the mapping status by the time gup_fast returns so...). And I didn't want to impact all gup/gup_fast users for now, maybe if we change the gup interface substantially we can avoid this locking, I admit I didn't think too much about it because changing the gup unpinning interface would be invasive.
If we ignored O_DIRECT we could stick to the existing compound refcounting code, by simply adding a get_user_pages_fast_flags(foll_flags) where KVM (and any other mmu notifier user) would call it without FOLL_GET (and if FOLL_GET isn't set we'd just BUG_ON if nobody registered itself in the current task mmu notifier list yet). But O_DIRECT is fundamental for decent performance of virtualized I/O on fast storage so we can't avoid it to solve the race of put_page against split_huge_page_refcount to achieve a complete hugepage feature for KVM.
Swap and oom works fine (well just like with regular pages ;). MMU notifier is handled transparently too, with the exception of the young bit on the pmd, that didn't have a range check but I think KVM will be fine because the whole point of hugepages is that EPT/NPT will also use a huge pmd when they notice gup returns pages with PageCompound set, so they won't care of a range and there's just the pmd young bit to check in that case.
NOTE: in some cases if the L2 cache is small, this may slowdown and waste memory during COWs because 4M of memory are accessed in a single fault instead of 8k (the payoff is that after COW the program can run faster). So we might want to switch the copy_huge_page (and clear_huge_page too) to not temporal stores. I also extensively researched ways to avoid this cache trashing with a full prefault logic that would cow in 8k/16k/32k/64k up to 1M (I can send those patches that fully implemented prefault) but I concluded they're not worth it and they add an huge additional complexity and they remove all tlb benefits until the full hugepage has been faulted in, to save a little bit of memory and some cache during app startup, but they still don't improve substantially the cache-trashing during startup if the prefault happens in >4k chunks. One reason is that those 4k pte entries copied are still mapped on a perfectly cache-colored hugepage, so the trashing is the worst one can generate in those copies (cow of 4k page copies aren't so well colored so they trashes less, but again this results in software running faster after the page fault). Those prefault patches allowed things like a pte where post-cow pages were local 4k regular anon pages and the not-yet-cowed pte entries were pointing in the middle of some hugepage mapped read-only. If it doesn't payoff substantially with todays hardware it will payoff even less in the future with larger l2 caches, and the prefault logic would blot the VM a lot. If one is emebdded transparent_hugepage can be disabled during boot with sysfs or with the boot commandline parameter transparent_hugepage=0 (or transparent_hugepage=2 to restrict hugepages inside madvise regions) that will ensure not a single hugepage is allocated at boot time. It is simple enough to just disable transparent hugepage globally and let transparent hugepages be allocated selectively by applications in the MADV_HUGEPAGE region (both at page fault time, and if enabled with the collapse_huge_page too through the kernel daemon).
This patch supports only hugepages mapped in the pmd, archs that have smaller hugepages will not fit in this patch alone. Also some archs like power have certain tlb limits that prevents mixing different page size in the same regions so they will not fit in this framework that requires "graceful fallback" to basic PAGE_SIZE in case of physical memory fragmentation. hugetlbfs remains a perfect fit for those because its software limits happen to match the hardware limits. hugetlbfs also remains a perfect fit for hugepage sizes like 1GByte that cannot be hoped to be found not fragmented after a certain system uptime and that would be very expensive to defragment with relocation, so requiring reservation. hugetlbfs is the "reservation way", the point of transparent hugepages is not to have any reservation at all and maximizing the use of cache and hugepages at all times automatically.
Some performance result:
vmx andrea # LD_PRELOAD=/usr/lib64/libhugetlbfs.so HUGETLB_MORECORE=yes HUGETLB_PATH=/mnt/huge/ ./largep ages3
memset page fault 1566023
memset tlb miss 453854
memset second tlb miss 453321
random access tlb miss 41635
random access second tlb miss 41658
vmx andrea # LD_PRELOAD=/usr/lib64/libhugetlbfs.so HUGETLB_MORECORE=yes HUGETLB_PATH=/mnt/huge/ ./largepages3 memset page fault 1566471
memset tlb miss 453375
memset second tlb miss 453320
random access tlb miss 41636
random access second tlb miss 41637
vmx andrea # ./largepages3
memset page fault 1566642
memset tlb miss 453417
memset second tlb miss 453313
random access tlb miss 41630
random access second tlb miss 41647
vmx andrea # ./largepages3
memset page fault 1566872
memset tlb miss 453418
memset second tlb miss 453315
random access tlb miss 41618
random access second tlb miss 41659
vmx andrea # echo 0 > /proc/sys/vm/transparent_hugepage
vmx andrea # ./largepages3
memset page fault 2182476
memset tlb miss 460305
memset second tlb miss 460179
random access tlb miss 44483
random access second tlb miss 44186
vmx andrea # ./largepages3
memset page fault 2182791
memset tlb miss 460742
memset second tlb miss 459962
random access tlb miss 43981
random access second tlb miss 43988
============
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/time.h>
#define SIZE (3UL*1024*1024*1024)
int main()
{
char *p = malloc(SIZE), *p2;
struct timeval before, after;
gettimeofday(&before, NULL);
memset(p, 0, SIZE);
gettimeofday(&after, NULL);
printf("memset page fault %Lu\n",
(after.tv_sec-before.tv_sec)*1000000UL +
after.tv_usec-before.tv_usec);
gettimeofday(&before, NULL);
memset(p, 0, SIZE);
gettimeofday(&after, NULL);
printf("memset tlb miss %Lu\n",
(after.tv_sec-before.tv_sec)*1000000UL +
after.tv_usec-before.tv_usec);
gettimeofday(&before, NULL);
memset(p, 0, SIZE);
gettimeofday(&after, NULL);
printf("memset second tlb miss %Lu\n",
(after.tv_sec-before.tv_sec)*1000000UL +
after.tv_usec-before.tv_usec);
gettimeofday(&before, NULL);
for (p2 = p; p2 < p+SIZE; p2 += 4096)
*p2 = 0;
gettimeofday(&after, NULL);
printf("random access tlb miss %Lu\n",
(after.tv_sec-before.tv_sec)*1000000UL +
after.tv_usec-before.tv_usec);
gettimeofday(&before, NULL);
for (p2 = p; p2 < p+SIZE; p2 += 4096)
*p2 = 0;
gettimeofday(&after, NULL);
printf("random access second tlb miss %Lu\n",
(after.tv_sec-before.tv_sec)*1000000UL +
after.tv_usec-before.tv_usec);
return 0;
}============
---
include/linux/huge_mm.h new file +128 -0
@@ -0,0 +1,128 @@ +#ifndef _LINUX_HUGE_MM_H +#define _LINUX_HUGE_MM_H + +extern int do_huge_pmd_anonymous_page (struct mm_struct *mm, +struct vm_area_struct *vma, +unsigned long address,pmd_t *pmd, +unsigned int flags); +extern int copy_huge_pmd (struct mm_struct *dst_mm,struct mm_struct *src_mm, +pmd_t *dst_pmd,pmd_t *src_pmd,unsigned long addr, +struct vm_area_struct *vma); +extern int do_huge_pmd_wp_page (struct mm_struct *mm,struct vm_area_struct *vma, +unsigned long address,pmd_t *pmd, +pmd_t orig_pmd); +extern pgtable_t get_pmd_huge_pte (struct mm_struct *mm); +extern struct page *follow_trans_huge_pmd (struct mm_struct *mm, +unsigned long addr, +pmd_t *pmd, +unsigned int flags); +extern int zap_huge_pmd (struct mmu_gather *tlb, +struct vm_area_struct *vma, +pmd_t *pmd); + +enum transparent_hugepage_flag { +TRANSPARENT_HUGEPAGE_FLAG , +TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG , +TRANSPARENT_HUGEPAGE_DEFRAG_FLAG , +TRANSPARENT_HUGEPAGE_DEFRAG_REQ_MADV_FLAG , +#ifdef CONFIG_DEBUG_VM +TRANSPARENT_HUGEPAGE_DEBUG_COW_FLAG , +#endif +}; + +enum page_check_address_pmd_flag { +PAGE_CHECK_ADDRESS_PMD_FLAG , +PAGE_CHECK_ADDRESS_PMD_NOTSPLITTING_FLAG , +PAGE_CHECK_ADDRESS_PMD_SPLITTING_FLAG , +}; +extern pmd_t *page_check_address_pmd (struct page *page, +struct mm_struct *mm, +unsigned long address, +enum page_check_address_pmd_flag flag); + +#define HPAGE_PMD_SHIFT HPAGE_SHIFT +#define HPAGE_PMD_MASK HPAGE_MASK +#define HPAGE_PMD_SIZE HPAGE_SIZE + +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +#define transparent_hugepage_enabled (__vma) \ + (transparent_hugepage_flags & (1<<TRANSPARENT_HUGEPAGE_FLAG) || \ + (transparent_hugepage_flags & \ + (1<<TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG) && \ + (__vma)->vm_flags & VM_HUGEPAGE)) +#define transparent_hugepage_defrag (__vma) \ + (transparent_hugepage_flags & \ + (1<<TRANSPARENT_HUGEPAGE_DEFRAG_FLAG) || \ + (transparent_hugepage_flags & \ + (1<<TRANSPARENT_HUGEPAGE_DEFRAG_REQ_MADV_FLAG) && \ + (__vma)->vm_flags & VM_HUGEPAGE)) +#ifdef CONFIG_DEBUG_VM +#define transparent_hugepage_debug_cow () \ + (transparent_hugepage_flags & \ + (1<<TRANSPARENT_HUGEPAGE_DEBUG_COW_FLAG)) +#else /* CONFIG_DEBUG_VM */ +#define transparent_hugepage_debug_cow () 0 +#endif /* CONFIG_DEBUG_VM */ + +extern unsigned long transparent_hugepage_flags; +extern int copy_pte_range (struct mm_struct *dst_mm,struct mm_struct *src_mm, +pmd_t *dst_pmd,pmd_t *src_pmd, +struct vm_area_struct *vma, +unsigned long addr,unsigned long end); +extern int handle_pte_fault (struct mm_struct *mm, +struct vm_area_struct *vma,unsigned long address, +pte_t *pte,pmd_t *pmd,unsigned int flags); +extern void __split_huge_page_mm (struct mm_struct *mm,unsigned long address, +pmd_t *pmd); +extern void __split_huge_page_vma (struct vm_area_struct *vma,pmd_t *pmd); +extern int split_huge_page (struct page *page); +#define split_huge_page_mm (__mm, __addr, __pmd) \ + do { \ + if (unlikely(pmd_trans_huge(*(__pmd)))) \ + __split_huge_page_mm(__mm, __addr, __pmd); \ + } while (0) +#define split_huge_page_vma (__vma, __pmd) \ + do { \ + if (unlikely(pmd_trans_huge(*(__pmd)))) \ + __split_huge_page_vma(__vma, __pmd); \ + } while (0) +#define wait_split_huge_page (__anon_vma, __pmd) \ + do { \ + smp_mb(); \ + spin_unlock_wait(&(__anon_vma)->lock); \ + smp_mb(); \ + VM_BUG_ON(pmd_trans_splitting(*(__pmd)) || \ + pmd_trans_huge(*(__pmd))); \ + } while (0) +#define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT) +#define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER) +#if HPAGE_PMD_ORDER >MAX_ORDER +#error "hugepages can't be allocated by the buddy allocator" +#endif + +extern unsigned long vma_address (struct page *page,struct vm_area_struct *vma); +static inline int PageTransHuge (struct page *page) +{ +VM_BUG_ON (PageTail (page)); +return PageHead (page); +} +#else /* CONFIG_TRANSPARENT_HUGEPAGE */ +#define transparent_hugepage_enabled (__vma) 0 +#define transparent_hugepage_defrag (__vma) 0 +#define transparent_hugepage_debug_cow () 0 + +#define transparent_hugepage_flags 0UL +static inline int split_huge_page (struct page *page) +{ +return 0 ; +} +#define split_huge_page_mm (__mm, __addr, __pmd) \ + do { } while (0) +#define split_huge_page_vma (__vma, __pmd) \ + do { } while (0) +#define wait_split_huge_page (__anon_vma, __pmd) \ + do { } while (0) +#define PageTransHuge (page) 0 +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ + +#endif /* _LINUX_HUGE_MM_H */
include/linux/mm.h +4 -0
@@ -106,6 +106,9 @@ extern unsigned int kobjsize(const void#define VM_SAO 0x20000000/* Strong Access Ordering (powerpc) */ #define VM_PFN_AT_MMAP 0x40000000/* PFNMAP vma that is fully mapped at mmap time */ #define VM_MERGEABLE 0x80000000/* KSM may merge identical pages */ +#if BITS_PER_LONG >32 +#define VM_HUGEPAGE 0x100000000UL/* MADV_HUGEPAGE marked this vma */ +#endif #ifndef VM_STACK_DEFAULT_FLAGS /* arch can override this */ #define VM_STACK_DEFAULT_FLAGS VM_DATA_DEFAULT_FLAGS
@@ -234,6 +237,7 @@ struct inode;* files which need it (119 of them) */ #include <linux/page-flags.h> +#include <linux/huge_mm.h> /* * Methods to modify the page usage count.
include/linux/mm_inline.h +10 -3
@@ -20,11 +20,18 @@ static inline int page_is_file_cache(str }static inline void +__add_page_to_lru_list (struct zone *zone,struct page *page,enum lru_list l, +struct list_head *head) +{ +list_add (&page->lru, head); +__inc_zone_state (zone,NR_LRU_BASE + l); +mem_cgroup_add_lru_list (page, l); +} + +static inline void add_page_to_lru_list (struct zone *zone,struct page *page,enum lru_list l) { -list_add (&page->lru, &zone->lru[l].list); -__inc_zone_state (zone,NR_LRU_BASE + l); -mem_cgroup_add_lru_list (page, l); +__add_page_to_lru_list (zone, page, l, &zone->lru[l].list); } static inline void
include/linux/swap.h +2 -0
@@ -205,6 +205,8 @@ extern unsigned int nr_free_pagecache_pa/* linux/mm/swap.c */ extern void __lru_cache_add (struct page *,enum lru_list lru);extern void lru_cache_add_lru (struct page *,enum lru_list lru); +extern void lru_add_page_tail (struct zone * zone, +struct page *page,struct page *page_tail);extern void activate_page (struct page *);extern void mark_page_accessed (struct page *);extern void lru_add_drain (void );
mm/Makefile +1 -0
@@ -40,3 +40,4 @@ obj-$(CONFIG_MEMORY_FAILURE) += memory-f obj-$(CONFIG_HWPOISON_INJECT) += hwpoison-inject.o obj-$(CONFIG_DEBUG_KMEMLEAK) += kmemleak.o obj-$(CONFIG_DEBUG_KMEMLEAK_TEST) += kmemleak-test.o +obj-$(CONFIG_TRANSPARENT_HUGEPAGE) += huge_memory.o
mm/huge_memory.c new file +848 -0
848 lines not on this page · raw message
mm/memory.c +60 -7
119 lines not on this page · raw message
mm/rmap.c +36 -23
93 lines not on this page · raw message
mm/swap.c +37 -0
@@ -461,6 +461,43 @@ void __pagevec_release(struct pagevec *pEXPORT_SYMBOL (__pagevec_release); +/* used by __split_huge_page_refcount() */ +void lru_add_page_tail (struct zone * zone, +struct page *page,struct page *page_tail) +{ +int active; +enum lru_list lru; +const int file =0 ; +struct list_head *head; + +VM_BUG_ON (!PageHead (page)); +VM_BUG_ON (PageCompound (page_tail)); +VM_BUG_ON (PageLRU (page_tail)); +VM_BUG_ON (!spin_is_locked (&zone->lru_lock)); + +SetPageLRU (page_tail); + +if (page_evictable (page_tail,NULL )) { +if (PageActive (page)) { +SetPageActive (page_tail); + active =1 ; + lru =LRU_ACTIVE_ANON ; + }else { + active =0 ; + lru =LRU_INACTIVE_ANON ; + } +update_page_reclaim_stat (zone, page_tail, file, active); +if (likely (PageLRU (page))) + head = page->lru.prev; +else + head = &zone->lru[lru].list; +__add_page_to_lru_list (zone, page_tail, lru, head); + }else { +SetPageUnevictable (page_tail); +add_page_to_lru_list (zone, page_tail,LRU_UNEVICTABLE ); + } +} +/* * Add the passed pages to the LRU, then drop the caller's refcount * on them. Reinitialises the caller's pagevec.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 25 of 31] transparent hugepage core
Quoted 5 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Lately I've been working to make KVM use hugepages transparently without the usual restrictions of hugetlbfs. Some of the restrictions I'd like to see removed:
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 add pmd mangling functions to x86
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Add needed pmd mangling functions with simmetry with their pte counterparts. pmdp_freeze_flush is the only exception only present on the pmd side and it's needed to serialize the VM against split_huge_page, it simply atomically clears the present bit in the same way pmdp_clear_flush_young atomically clears the accessed bit (and both need to flush the tlb to make it effective, which is mandatory to happen synchronously for pmdp_freeze_flush).
---
arch/x86/include/asm/pgtable.h +92 -1
@@ -150,6 +150,67 @@ static inline pte_t pte_set_flags(pte_treturn native_make_pte (v | set); } +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +static inline int pmd_young (pmd_t pmd) +{ +return pmd_flags (pmd) & _PAGE_ACCESSED; +} + +static inline int pmd_write (pmd_t pmd) +{ +return pmd_flags (pmd) & _PAGE_RW; +} + +static inline pmd_t pmd_set_flags (pmd_t pmd,pmdval_t set) +{ +pmdval_t v =native_pmd_val (pmd); + +return native_make_pmd (v | set); +} + +static inline pmd_t pmd_clear_flags (pmd_t pmd,pmdval_t clear) +{ +pmdval_t v =native_pmd_val (pmd); + +return native_make_pmd (v & ~clear); +} + +static inline pmd_t pmd_mkold (pmd_t pmd) +{ +return pmd_clear_flags (pmd, _PAGE_ACCESSED); +} + +static inline pmd_t pmd_wrprotect (pmd_t pmd) +{ +return pmd_clear_flags (pmd, _PAGE_RW); +} + +static inline pmd_t pmd_mkdirty (pmd_t pmd) +{ +return pmd_set_flags (pmd, _PAGE_DIRTY); +} + +static inline pmd_t pmd_mkhuge (pmd_t pmd) +{ +return pmd_set_flags (pmd, _PAGE_PSE); +} + +static inline pmd_t pmd_mkyoung (pmd_t pmd) +{ +return pmd_set_flags (pmd, _PAGE_ACCESSED); +} + +static inline pmd_t pmd_mkwrite (pmd_t pmd) +{ +return pmd_set_flags (pmd, _PAGE_RW); +} + +static inline int pmd_same (pmd_t a,pmd_t b) +{ +return a.pmd == b.pmd; +} +#endif +static inline pte_t pte_clear_flags (pte_t pte,pteval_t clear) {pteval_t v =native_pte_val (pte);
@@ -351,7 +412,7 @@ static inline unsigned long pmd_page_vad* Currently stuck as a macro due to indirect forward reference to * linux/mmzone.h's __section_mem_map_addr() definition: */ -#define pmd_page (pmd) pfn_to_page(pmd_val(pmd) >> PAGE_SHIFT) +#define pmd_page (pmd) pfn_to_page((pmd_val(pmd) & PTE_PFN_MASK) >> PAGE_SHIFT)/* * the pmd page can be thought of an array like this: pmd_t[PTRS_PER_PMD]
@@ -372,6 +433,7 @@ static inline unsigned long pmd_index(un* to linux/mm.h:page_to_nid()) */ #define mk_pte (page, pgprot) pfn_pte(page_to_pfn(page), (pgprot)) +#define mk_pmd (page, pgprot) pfn_pmd(page_to_pfn(page), (pgprot))/* * the pte page can be thought of an array like this: pte_t[PTRS_PER_PTE]
@@ -568,14 +630,21 @@ struct vm_area_struct;extern int ptep_set_access_flags (struct vm_area_struct *vma,unsigned long address,pte_t *ptep,pte_t entry,int dirty); +extern int pmdp_set_access_flags (struct vm_area_struct *vma, +unsigned long address,pmd_t *pmdp, +pmd_t entry,int dirty);#define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNGextern int ptep_test_and_clear_young (struct vm_area_struct *vma,unsigned long addr,pte_t *ptep); +extern int pmdp_test_and_clear_young (struct vm_area_struct *vma, +unsigned long addr,pmd_t *pmdp);#define __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSHextern int ptep_clear_flush_young (struct vm_area_struct *vma,unsigned long address,pte_t *ptep); +extern int pmdp_clear_flush_young (struct vm_area_struct *vma, +unsigned long address,pmd_t *pmdp);#define __HAVE_ARCH_PTEP_GET_AND_CLEAR static inline pte_t ptep_get_and_clear(struct mm_struct *mm, unsigned long addr,
@@ -586,6 +655,16 @@ static inline pte_t ptep_get_and_clear(sreturn pte; } +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +static inline pmd_t pmdp_get_and_clear (struct mm_struct *mm,unsigned long addr, +pmd_t *pmdp) +{ +pmd_t pmd =native_pmdp_get_and_clear (pmdp); +pmd_update (mm, addr, pmdp); +return pmd; +} +#endif +#define __HAVE_ARCH_PTEP_GET_AND_CLEAR_FULL static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm, unsigned long addr, pte_t *ptep,
@@ -612,6 +691,18 @@ static inline void ptep_set_wrprotect(stpte_update (mm, addr, ptep); } +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +static inline void pmdp_set_wrprotect (struct mm_struct *mm, +unsigned long addr,pmd_t *pmdp) +{ +clear_bit (_PAGE_BIT_RW, (unsigned long *)&pmdp->pmd); +pmd_update (mm, addr, pmdp); +} +#endif + +extern void pmdp_splitting_flush (struct vm_area_struct *vma, +unsigned long addr,pmd_t *pmdp); +/* * clone_pgd_range(pgd_t *dst, pgd_t *src, int count); *
arch/x86/include/asm/pgtable_64.h +12 -0
@@ -71,6 +71,18 @@ static inline pte_t native_ptep_get_and_return ret;#endif } +static inline pmd_t native_pmdp_get_and_clear (pmd_t *xp) +{ +#ifdef CONFIG_SMP +return native_make_pmd (xchg (&xp->pmd,0 )); +#else +/* native_local_pmdp_get_and_clear, +but duplicated because of cyclic dependency */ +pmd_t ret = *xp; +native_pmd_clear (NULL ,0 , xp); +return ret; +#endif +}static inline void native_set_pmd (pmd_t *pmdp,pmd_t pmd) {
arch/x86/mm/pgtable.c +66 -0
84 lines not on this page · raw message
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 13 of 31] add pmd mangling functions to x86
Quoted 10 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Add needed pmd mangling functions with simmetry with their pte counterparts.
pmdp_freeze_flushis the only exception only present on the pmd side and it's needed to serialize the VM againstsplit_huge_page, it simply atomically clears the present bit in the same waypmdp_clear_flush_youngatomically clears the accessed bit (and both need to flush the tlb to make it effective, which is mandatory to happen synchronously forpmdp_freeze_flush).Signed-off-by Andrea Arcangeli<[email protected]>
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 13 of 31] add pmd mangling functions to x86
In reply to Andrea ArcangeliQuoted 10 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
Add needed pmd mangling functions with simmetry with their pte counterparts.
pmdp_freeze_flushis the only exception only present on the pmd side and it's needed to serialize the VM againstsplit_huge_page, it simply atomically clears the present bit in the same waypmdp_clear_flush_youngatomically clears the accessed bit (and both need to flush the tlb to make it effective, which is mandatory to happen synchronously forpmdp_freeze_flush).Signed-off-by Andrea Arcangeli <[email protected]>
Does pmdp_splitting_flush() belong in this set? I don't think _PAGE_BIT_SPLITTING has been defined yet for example. Other than that, it looked ok.
Quoted 261 lines
---
arch/x86/include/asm/pgtable.h +92
-1@@ -150,6 +150,67 @@ static inline pte_t pte_set_flags(pte_treturn native_make_pte (v | set); } +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +static inline int pmd_young (pmd_t pmd) +{ +return pmd_flags (pmd) & _PAGE_ACCESSED; +} + +static inline int pmd_write (pmd_t pmd) +{ +return pmd_flags (pmd) & _PAGE_RW; +} + +static inline pmd_t pmd_set_flags (pmd_t pmd,pmdval_t set) +{ +pmdval_t v =native_pmd_val (pmd); + +return native_make_pmd (v | set); +} + +static inline pmd_t pmd_clear_flags (pmd_t pmd,pmdval_t clear) +{ +pmdval_t v =native_pmd_val (pmd); + +return native_make_pmd (v & ~clear); +} + +static inline pmd_t pmd_mkold (pmd_t pmd) +{ +return pmd_clear_flags (pmd, _PAGE_ACCESSED); +} + +static inline pmd_t pmd_wrprotect (pmd_t pmd) +{ +return pmd_clear_flags (pmd, _PAGE_RW); +} + +static inline pmd_t pmd_mkdirty (pmd_t pmd) +{ +return pmd_set_flags (pmd, _PAGE_DIRTY); +} + +static inline pmd_t pmd_mkhuge (pmd_t pmd) +{ +return pmd_set_flags (pmd, _PAGE_PSE); +} + +static inline pmd_t pmd_mkyoung (pmd_t pmd) +{ +return pmd_set_flags (pmd, _PAGE_ACCESSED); +} + +static inline pmd_t pmd_mkwrite (pmd_t pmd) +{ +return pmd_set_flags (pmd, _PAGE_RW); +} + +static inline int pmd_same (pmd_t a,pmd_t b) +{ +return a.pmd == b.pmd; +} +#endif +static inline pte_t pte_clear_flags (pte_t pte,pteval_t clear) {pteval_t v =native_pte_val (pte);@@ -351,7 +412,7 @@ static inline unsigned long pmd_page_vad* Currently stuck as a macro due to indirect forward reference to * linux/mmzone.h's __section_mem_map_addr() definition: */ -#define pmd_page (pmd) pfn_to_page(pmd_val(pmd) >> PAGE_SHIFT) +#define pmd_page (pmd) pfn_to_page((pmd_val(pmd) & PTE_PFN_MASK) >> PAGE_SHIFT)/* * the pmd page can be thought of an array like this: pmd_t[PTRS_PER_PMD] @@ -372,6 +433,7 @@ static inline unsigned long pmd_index(un* to linux/mm.h:page_to_nid()) */ #define mk_pte (page, pgprot) pfn_pte(page_to_pfn(page), (pgprot)) +#define mk_pmd (page, pgprot) pfn_pmd(page_to_pfn(page), (pgprot))/* * the pte page can be thought of an array like this: pte_t[PTRS_PER_PTE] @@ -568,14 +630,21 @@ struct vm_area_struct;extern int ptep_set_access_flags (struct vm_area_struct *vma,unsigned long address,pte_t *ptep,pte_t entry,int dirty); +extern int pmdp_set_access_flags (struct vm_area_struct *vma, +unsigned long address,pmd_t *pmdp, +pmd_t entry,int dirty);#define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNGextern int ptep_test_and_clear_young (struct vm_area_struct *vma,unsigned long addr,pte_t *ptep); +extern int pmdp_test_and_clear_young (struct vm_area_struct *vma, +unsigned long addr,pmd_t *pmdp);#define __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSHextern int ptep_clear_flush_young (struct vm_area_struct *vma,unsigned long address,pte_t *ptep); +extern int pmdp_clear_flush_young (struct vm_area_struct *vma, +unsigned long address,pmd_t *pmdp);#define __HAVE_ARCH_PTEP_GET_AND_CLEAR static inline pte_t ptep_get_and_clear(struct mm_struct *mm, unsigned long addr,@@ -586,6 +655,16 @@ static inline pte_t ptep_get_and_clear(sreturn pte; } +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +static inline pmd_t pmdp_get_and_clear (struct mm_struct *mm,unsigned long addr, +pmd_t *pmdp) +{ +pmd_t pmd =native_pmdp_get_and_clear (pmdp); +pmd_update (mm, addr, pmdp); +return pmd; +} +#endif +#define __HAVE_ARCH_PTEP_GET_AND_CLEAR_FULL static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm, unsigned long addr, pte_t *ptep,@@ -612,6 +691,18 @@ static inline void ptep_set_wrprotect(stpte_update (mm, addr, ptep); } +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +static inline void pmdp_set_wrprotect (struct mm_struct *mm, +unsigned long addr,pmd_t *pmdp) +{ +clear_bit (_PAGE_BIT_RW, (unsigned long *)&pmdp->pmd); +pmd_update (mm, addr, pmdp); +} +#endif + +extern void pmdp_splitting_flush (struct vm_area_struct *vma, +unsigned long addr,pmd_t *pmdp); +/* * clone_pgd_range(pgd_t *dst, pgd_t *src, int count); * arch/x86/include/asm/pgtable_64.h +12
-0@@ -71,6 +71,18 @@ static inline pte_t native_ptep_get_and_return ret;#endif } +static inline pmd_t native_pmdp_get_and_clear (pmd_t *xp) +{ +#ifdef CONFIG_SMP +return native_make_pmd (xchg (&xp->pmd,0 )); +#else +/* native_local_pmdp_get_and_clear, +but duplicated because of cyclic dependency */ +pmd_t ret = *xp; +native_pmd_clear (NULL ,0 , xp); +return ret; +#endif +}static inline void native_set_pmd (pmd_t *pmdp,pmd_t pmd) {arch/x86/mm/pgtable.c +66
-0@@ -288,6 +288,25 @@ int ptep_set_access_flags(struct vm_areareturn changed; } +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +int pmdp_set_access_flags (struct vm_area_struct *vma, +unsigned long address,pmd_t *pmdp, +pmd_t entry,int dirty) +{ +int changed = !pmd_same (*pmdp, entry); + +VM_BUG_ON (address & ~HPAGE_PMD_MASK ); + +if (changed && dirty) { + *pmdp = entry; +pmd_update_defer (vma->vm_mm, address, pmdp); +flush_tlb_range (vma, address, address +HPAGE_PMD_SIZE ); + } + +return changed; +} +#endif +int ptep_test_and_clear_young (struct vm_area_struct *vma,unsigned long addr,pte_t *ptep) {@@ -303,6 +322,23 @@ int ptep_test_and_clear_young(struct vm_return ret; } +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +int pmdp_test_and_clear_young (struct vm_area_struct *vma, +unsigned long addr,pmd_t *pmdp) +{ +int ret =0 ; + +if (pmd_young (*pmdp)) + ret =test_and_clear_bit (_PAGE_BIT_ACCESSED, + (unsigned long *) &pmdp->pmd); + +if (ret) +pmd_update (vma->vm_mm, addr, pmdp); + +return ret; +} +#endif +int ptep_clear_flush_young (struct vm_area_struct *vma,unsigned long address,pte_t *ptep) {@@ -315,6 +351,36 @@ int ptep_clear_flush_young(struct vm_arereturn young; } +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +int pmdp_clear_flush_young (struct vm_area_struct *vma, +unsigned long address,pmd_t *pmdp) +{ +int young; + +VM_BUG_ON (address & ~HPAGE_PMD_MASK ); + + young =pmdp_test_and_clear_young (vma, address, pmdp); +if (young) +flush_tlb_range (vma, address, address +HPAGE_PMD_SIZE ); + +return young; +} + +void pmdp_splitting_flush (struct vm_area_struct *vma, +unsigned long address,pmd_t *pmdp) +{ +int set; +VM_BUG_ON (address & ~HPAGE_PMD_MASK ); + set = !test_and_set_bit (_PAGE_BIT_SPLITTING, + (unsigned long *)&pmdp->pmd); +if (set) { +pmd_update (vma->vm_mm, address, pmdp); +/* need tlb flush only to serialize against gup-fast */ +flush_tlb_range (vma, address, address +HPAGE_PMD_SIZE ); + } +} +#endif +/** * reserve_top_address - reserves a hole in the top of kernel address space * @reserve - size of hole to reserve
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 13 of 31] add pmd mangling functions to x86
Quoted 10 lines · Mel Gorman
Quoted 9 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
Add needed pmd mangling functions with simmetry with their pte counterparts.
pmdp_freeze_flushis the only exception only present on the pmd side and it's needed to serialize the VM againstsplit_huge_page, it simply atomically clears the present bit in the same waypmdp_clear_flush_youngatomically clears the accessed bit (and both need to flush the tlb to make it effective, which is mandatory to happen synchronously forpmdp_freeze_flush).
Quoted 5 lines
Quoted 1 line
Signed-off-by Andrea Arcangeli <[email protected]>Does
pmdp_splitting_flush()belong in this set? I don't think_PAGE_BIT_SPLITTINGhas been defined yet for example. Other than that, it looked ok.
It is set in pmd_trans:
pmd_mangling_x86pmd_mangling_genericpmd_trans
I'll reverse the order to:
pmd_transpmd_mangling_x86pmd_mangling_generic
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 special pmd_trans_* functions
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
These returns 0 at compile time when the config option is disabled, to allow gcc to eliminate the transparent hugepage function calls at compile time without additional #ifdefs (only the export of those functions have to be visible to gcc but they won't be required at link time and huge_memory.o can be not built at all).
---
arch/x86/include/asm/pgtable.h +12 -0
@@ -396,6 +396,18 @@ static inline int pmd_present(pmd_t pmd)return pmd_flags (pmd) & _PAGE_PRESENT; } +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +static inline int pmd_trans_splitting (pmd_t pmd) +{ +return pmd_val (pmd) & _PAGE_SPLITTING; +} + +static inline int pmd_trans_huge (pmd_t pmd) +{ +return pmd_val (pmd) & _PAGE_PSE; +} +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ +static inline int pmd_none (pmd_t pmd) {/* Only check low word on 32-bit platforms, since it might be
arch/x86/include/asm/pgtable_types.h +2 -0
@@ -22,6 +22,7 @@#define _PAGE_BIT_PAT_LARGE 12/* On 2MB or 1GB pages */ #define _PAGE_BIT_SPECIAL _PAGE_BIT_UNUSED1#define _PAGE_BIT_CPA_TEST _PAGE_BIT_UNUSED1 +#define _PAGE_BIT_SPLITTING _PAGE_BIT_UNUSED1/* only valid on a PSE pmd */ #define _PAGE_BIT_NX 63/* No execute: only valid after cpuid check */ /* If _PAGE_BIT_PRESENT is clear, we use these: */
@@ -45,6 +46,7 @@#define _PAGE_PAT_LARGE (_AT(pteval_t, 1) << _PAGE_BIT_PAT_LARGE)#define _PAGE_SPECIAL (_AT(pteval_t, 1) << _PAGE_BIT_SPECIAL)#define _PAGE_CPA_TEST (_AT(pteval_t, 1) << _PAGE_BIT_CPA_TEST) +#define _PAGE_SPLITTING (_AT(pteval_t, 1) << _PAGE_BIT_SPLITTING)#define __HAVE_ARCH_PTE_SPECIAL#ifdef CONFIG_KMEMCHECK
include/asm-generic/pgtable.h +2 -0
@@ -412,6 +412,8 @@ extern void untrack_pfn_vma(struct vm_ar#ifndef CONFIG_TRANSPARENT_HUGEPAGE #define pmd_write (pmd) 0 +#define pmd_trans_huge (pmd) 0 +#define pmd_trans_splitting (pmd) 0#endif #endif /* !__ASSEMBLY__ */
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 15 of 31] special pmd_trans_* functions
Quoted 9 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
These returns 0 at compile time when the config option is disabled, to allow gcc to eliminate the transparent hugepage function calls at compile time without additional #ifdefs (only the export of those functions have to be visible to gcc but they won't be required at link time and huge_memory.o can be not built at all).
Signed-off-by Andrea Arcangeli<[email protected]>
Took me a few minutes to figure out why reusing that bit in the page table entry is safe. IMHO that could use a more verbose changelog message.
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 pte alloc trans splitting
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
pte alloc routines must wait for split_huge_page if the pmd is not present and not null (i.e. pmd_trans_splitting). The additional branches are optimized away at compile time by pmd_trans_splitting if the config option is off. However we must pass the vma down in order to know the anon_vma lock to wait for.
---
include/linux/mm.h +8 -5
@@ -955,7 +955,8 @@ static inline int __pmd_alloc(struct mm_int __pmd_alloc (struct mm_struct *mm,pud_t *pud,unsigned long address);#endif -int __pte_alloc (struct mm_struct *mm,pmd_t *pmd,unsigned long address); +int __pte_alloc (struct mm_struct *mm,struct vm_area_struct *vma, +pmd_t *pmd,unsigned long address);int __pte_alloc_kernel (pmd_t *pmd,unsigned long address);/*
@@ -1024,12 +1025,14 @@ static inline void pgtable_page_dtor(strpte_unmap (pte); \ } while (0) -#define pte_alloc_map (mm, pmd, address) \ - ((unlikely(!pmd_present(*(pmd))) && __pte_alloc(mm, pmd, address))? \ - NULL: pte_offset_map(pmd, address)) +#define pte_alloc_map (mm, vma, pmd, address) \ + ((unlikely(!pmd_present(*(pmd))) && __pte_alloc(mm, vma, \ + pmd, address))? \ + NULL: pte_offset_map(pmd, address))#define pte_alloc_map_lock (mm, pmd, address, ptlp) \ - ((unlikely(!pmd_present(*(pmd))) && __pte_alloc(mm, pmd, address))? \ + ((unlikely(!pmd_present(*(pmd))) && __pte_alloc(mm, NULL, \ + pmd, address))? \ NULL: pte_offset_map_lock(mm, pmd, address, ptlp))#define pte_alloc_kernel (pmd, address) \
mm/memory.c +13 -6
@@ -324,9 +324,11 @@ void free_pgtables(struct mmu_gather *tl } } -int __pte_alloc (struct mm_struct *mm,pmd_t *pmd,unsigned long address) +int __pte_alloc (struct mm_struct *mm,struct vm_area_struct *vma, +pmd_t *pmd,unsigned long address) {pgtable_t new =pte_alloc_one (mm, address); +int wait_split_huge_page;if (!new)return -ENOMEM ;
@@ -346,14 +348,18 @@ int __pte_alloc(struct mm_struct *mm, pmsmp_wmb ();/* Could be smp_wmb__xxx(before|after)_spin_lock */ spin_lock (&mm->page_table_lock); -if (!pmd_present (*pmd)) {/* Has another populated it ? */ + wait_split_huge_page =0 ; +if (likely (pmd_none (*pmd))) {/* Has another populated it ? */ mm->nr_ptes++;pmd_populate (mm, pmd, new); new =NULL ; - } + }else if (unlikely (pmd_trans_splitting (*pmd))) + wait_split_huge_page =1 ;spin_unlock (&mm->page_table_lock);if (new)pte_free (mm, new); +if (wait_split_huge_page) +wait_split_huge_page (vma->anon_vma, pmd);return 0 ; }
@@ -366,10 +372,11 @@ int __pte_alloc_kernel(pmd_t *pmd, unsigsmp_wmb ();/* See comment in __pte_alloc */ spin_lock (&init_mm.page_table_lock); -if (!pmd_present (*pmd)) {/* Has another populated it ? */ +if (likely (pmd_none (*pmd))) {/* Has another populated it ? */ pmd_populate_kernel (&init_mm, pmd, new); new =NULL ; - } + }else +VM_BUG_ON (pmd_trans_splitting (*pmd));spin_unlock (&init_mm.page_table_lock);if (new)pte_free_kernel (&init_mm, new);
@@ -3020,7 +3027,7 @@ int handle_mm_fault(struct mm_struct *mm pmd =pmd_alloc (mm, pud, address);if (!pmd)return VM_FAULT_OOM ; - pte =pte_alloc_map (mm, pmd, address); + pte =pte_alloc_map (mm, vma, pmd, address);if (!pte)return VM_FAULT_OOM ;
mm/mremap.c +4 -3
@@ -48,7 +48,8 @@ static pmd_t *get_old_pmd(struct mm_strureturn pmd; } -static pmd_t *alloc_new_pmd (struct mm_struct *mm,unsigned long addr) +static pmd_t *alloc_new_pmd (struct mm_struct *mm,struct vm_area_struct *vma, +unsigned long addr) {pgd_t *pgd;pud_t *pud;
@@ -63,7 +64,7 @@ static pmd_t *alloc_new_pmd(struct mm_stif (!pmd)return NULL ; -if (!pmd_present (*pmd) &&__pte_alloc (mm, pmd, addr)) +if (!pmd_present (*pmd) &&__pte_alloc (mm, vma, pmd, addr))return NULL ;return pmd;
@@ -148,7 +149,7 @@ unsigned long move_page_tables(struct vm old_pmd =get_old_pmd (vma->vm_mm, old_addr);if (!old_pmd)continue ; - new_pmd =alloc_new_pmd (vma->vm_mm, new_addr); + new_pmd =alloc_new_pmd (vma->vm_mm, vma, new_addr);if (!new_pmd)break ; next = (new_addr +PMD_SIZE ) &PMD_MASK ;
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 17 of 31] pte alloc trans splitting
Quoted 9 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
pte alloc routines must wait for
split_huge_pageif the pmd is not present and not null (i.e.pmd_trans_splitting). The additional branches are optimized away at compile time bypmd_trans_splittingif the config option is off. However we must pass the vma down in order to know theanon_vmalock to wait for.Signed-off-by Andrea Arcangeli<[email protected]>
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 17 of 31] pte alloc trans splitting
In reply to Andrea ArcangeliQuoted 9 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
pte alloc routines must wait for
split_huge_pageif the pmd is not present and not null (i.e.pmd_trans_splitting). The additional branches are optimized away at compile time bypmd_trans_splittingif the config option is off. However we must pass the vma down in order to know theanon_vmalock to wait for.Signed-off-by Andrea Arcangeli <[email protected]>
Quoted 126 lines
---
include/linux/mm.h +8
-5@@ -955,7 +955,8 @@ static inline int __pmd_alloc(struct mm_int __pmd_alloc (struct mm_struct *mm,pud_t *pud,unsigned long address);#endif -int __pte_alloc (struct mm_struct *mm,pmd_t *pmd,unsigned long address); +int __pte_alloc (struct mm_struct *mm,struct vm_area_struct *vma, +pmd_t *pmd,unsigned long address);int __pte_alloc_kernel (pmd_t *pmd,unsigned long address);/* @@ -1024,12 +1025,14 @@ static inline void pgtable_page_dtor(strpte_unmap (pte); \ } while (0) -#define pte_alloc_map (mm, pmd, address) \ - ((unlikely(!pmd_present(*(pmd))) && __pte_alloc(mm, pmd, address))? \ - NULL: pte_offset_map(pmd, address)) +#define pte_alloc_map (mm, vma, pmd, address) \ + ((unlikely(!pmd_present(*(pmd))) && __pte_alloc(mm, vma, \ + pmd, address))? \ + NULL: pte_offset_map(pmd, address))#define pte_alloc_map_lock (mm, pmd, address, ptlp) \ - ((unlikely(!pmd_present(*(pmd))) && __pte_alloc(mm, pmd, address))? \ + ((unlikely(!pmd_present(*(pmd))) && __pte_alloc(mm, NULL, \ + pmd, address))? \ NULL: pte_offset_map_lock(mm, pmd, address, ptlp))#define pte_alloc_kernel (pmd, address) \mm/memory.c +13
-6@@ -324,9 +324,11 @@ void free_pgtables(struct mmu_gather *tl } } -int __pte_alloc (struct mm_struct *mm,pmd_t *pmd,unsigned long address) +int __pte_alloc (struct mm_struct *mm,struct vm_area_struct *vma, +pmd_t *pmd,unsigned long address) {pgtable_t new =pte_alloc_one (mm, address); +int wait_split_huge_page;if (!new)return -ENOMEM ;@@ -346,14 +348,18 @@ int __pte_alloc(struct mm_struct *mm, pmsmp_wmb ();/* Could be smp_wmb__xxx(before|after)_spin_lock */ spin_lock (&mm->page_table_lock); -if (!pmd_present (*pmd)) {/* Has another populated it ? */ + wait_split_huge_page =0 ; +if (likely (pmd_none (*pmd))) {/* Has another populated it ? */ mm->nr_ptes++;pmd_populate (mm, pmd, new); new =NULL ; - } + }else if (unlikely (pmd_trans_splitting (*pmd))) + wait_split_huge_page =1 ;spin_unlock (&mm->page_table_lock);if (new)pte_free (mm, new); +if (wait_split_huge_page) +wait_split_huge_page (vma->anon_vma, pmd);return 0 ; }@@ -366,10 +372,11 @@ int __pte_alloc_kernel(pmd_t *pmd, unsigsmp_wmb ();/* See comment in __pte_alloc */ spin_lock (&init_mm.page_table_lock); -if (!pmd_present (*pmd)) {/* Has another populated it ? */ +if (likely (pmd_none (*pmd))) {/* Has another populated it ? */ pmd_populate_kernel (&init_mm, pmd, new); new =NULL ; - } + }else +VM_BUG_ON (pmd_trans_splitting (*pmd));spin_unlock (&init_mm.page_table_lock);if (new)pte_free_kernel (&init_mm, new);@@ -3020,7 +3027,7 @@ int handle_mm_fault(struct mm_struct *mm pmd =pmd_alloc (mm, pud, address);if (!pmd)return VM_FAULT_OOM ; - pte =pte_alloc_map (mm, pmd, address); + pte =pte_alloc_map (mm, vma, pmd, address);if (!pte)return VM_FAULT_OOM ;mm/mremap.c +4
-3@@ -48,7 +48,8 @@ static pmd_t *get_old_pmd(struct mm_strureturn pmd; } -static pmd_t *alloc_new_pmd (struct mm_struct *mm,unsigned long addr) +static pmd_t *alloc_new_pmd (struct mm_struct *mm,struct vm_area_struct *vma, +unsigned long addr) {pgd_t *pgd;pud_t *pud;@@ -63,7 +64,7 @@ static pmd_t *alloc_new_pmd(struct mm_stif (!pmd)return NULL ; -if (!pmd_present (*pmd) &&__pte_alloc (mm, pmd, addr)) +if (!pmd_present (*pmd) &&__pte_alloc (mm, vma, pmd, addr))return NULL ;return pmd;@@ -148,7 +149,7 @@ unsigned long move_page_tables(struct vm old_pmd =get_old_pmd (vma->vm_mm, old_addr);if (!old_pmd)continue ; - new_pmd =alloc_new_pmd (vma->vm_mm, new_addr); + new_pmd =alloc_new_pmd (vma->vm_mm, vma, new_addr);if (!new_pmd)break ; next = (new_addr +PMD_SIZE ) &PMD_MASK ;
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 fix bad_page to show the real reason the page is bad
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
page_count shows the count of the head page, but the actual check is done on the tail page, so show what is really being checked.
---
mm/page_alloc.c +1 -1
@@ -265,7 +265,7 @@ static void bad_page(struct page *page) current->comm, page_to_pfn(page));printk (KERN_ALERT "page:%p flags:%p count:%d mapcount:%d mapping:%p index:%lx\n" , - page, (void *)page->flags,page_count (page), + page, (void *)page->flags,atomic_read (&page->_count),page_mapcount (page), page->mapping, page->index);dump_stack ();
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 05 of 31] fix bad_page to show the real reason the page is bad
Quoted 6 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
page_countshows the count of the head page, but the actual check is done on the tail page, so show what is really being checked.Signed-off-by Andrea Arcangeli<[email protected]>
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 05 of 31] fix bad_page to show the real reason the page is bad
In reply to Andrea ArcangeliQuoted 6 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
page_countshows the count of the head page, but the actual check is done on the tail page, so show what is really being checked.Signed-off-by Andrea Arcangeli <[email protected]>
Quoted 15 lines
---
mm/page_alloc.c +1
-1@@ -265,7 +265,7 @@ static void bad_page(struct page *page) current->comm, page_to_pfn(page));printk (KERN_ALERT "page:%p flags:%p count:%d mapcount:%d mapping:%p index:%lx\n" , - page, (void *)page->flags,page_count (page), + page, (void *)page->flags,atomic_read (&page->_count),page_mapcount (page), page->mapping, page->index);dump_stack ();
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 add pmd mangling generic functions
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Some are needed to build but not actually used on archs not supporting transparent hugepages. Others like pmdp_clear_flush are used by x86 too.
---
include/asm-generic/pgtable.h +70 -0
@@ -23,6 +23,19 @@ } \ __changed; \ }) + +#define pmdp_set_access_flags (__vma, __address, __pmdp, __entry, __dirty) \ + ({ \ + int __changed = !pmd_same(*(__pmdp), __entry); \ + VM_BUG_ON((__address) & ~HPAGE_PMD_MASK); \ + if (__changed) { \ + set_pmd_at((__vma)->vm_mm, __address, __pmdp, \ + __entry); \ + flush_tlb_range(__vma, __address, \ + (__address) + HPAGE_PMD_SIZE); \ + } \ + __changed; \ + })#endif #ifndef __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG
@@ -37,6 +50,17 @@ (__ptep), pte_mkold(__pte)); \ r; \ }) +#define pmdp_test_and_clear_young (__vma, __address, __pmdp) \ +({ \ + pmd_t __pmd = *(__pmdp); \ + int r = 1; \ + if (!pmd_young(__pmd)) \ + r = 0; \ + else \ + set_pmd_at((__vma)->vm_mm, (__address), \ + (__pmdp), pmd_mkold(__pmd)); \ + r; \ +})#endif #ifndef __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH
@@ -48,6 +72,16 @@flush_tlb_page (__vma, __address); \ __young; \ }) +#define pmdp_clear_flush_young (__vma, __address, __pmdp) \ +({ \ + int __young; \ + VM_BUG_ON((__address) & ~HPAGE_PMD_MASK); \ + __young = pmdp_test_and_clear_young(__vma, __address, __pmdp); \ + if (__young) \ + flush_tlb_range(__vma, __address, \ + (__address) + HPAGE_PMD_SIZE); \ + __young; \ +})#endif #ifndef __HAVE_ARCH_PTEP_GET_AND_CLEAR
@@ -57,6 +91,13 @@pte_clear ((__mm), (__address), (__ptep)); \ __pte; \ }) + +#define pmdp_get_and_clear (__mm, __address, __pmdp) \ +({ \ + pmd_t __pmd = *(__pmdp); \ + pmd_clear((__mm), (__address), (__pmdp)); \ + __pmd; \ +})#endif #ifndef __HAVE_ARCH_PTEP_GET_AND_CLEAR_FULL
@@ -88,6 +129,15 @@ do { \flush_tlb_page (__vma, __address); \ __pte; \ }) + +#define pmdp_clear_flush (__vma, __address, __pmdp) \ +({ \ + pmd_t __pmd; \ + VM_BUG_ON((__address) & ~HPAGE_PMD_MASK); \ + __pmd = pmdp_get_and_clear((__vma)->vm_mm, __address, __pmdp); \ + flush_tlb_range(__vma, __address, (__address) + HPAGE_PMD_SIZE);\ + __pmd; \ +})#endif #ifndef __HAVE_ARCH_PTEP_SET_WRPROTECT
@@ -97,10 +147,26 @@ static inline void ptep_set_wrprotect(stpte_t old_pte = *ptep;set_pte_at (mm, address, ptep,pte_wrprotect (old_pte)); } + +static inline void pmdp_set_wrprotect (struct mm_struct *mm,unsigned long address,pmd_t *pmdp) +{ +pmd_t old_pmd = *pmdp; +set_pmd_at (mm, address, pmdp,pmd_wrprotect (old_pmd)); +} + +#define pmdp_splitting_flush (__vma, __address, __pmdp) \ +({ \ + pmd_t __pmd = pmd_mksplitting(*(__pmdp)); \ + VM_BUG_ON((__address) & ~HPAGE_PMD_MASK); \ + set_pmd_at((__vma)->vm_mm, __address, __pmdp, __pmd); \ +/* tlb flush only to serialize against gup-fast */ \ +flush_tlb_range (__vma, __address, (__address) +HPAGE_PMD_SIZE );\ +})#endif #ifndef __HAVE_ARCH_PTE_SAME#define pte_same (A ,B ) (pte_val(A) == pte_val(B)) +#define pmd_same (A ,B ) (pmd_val(A) == pmd_val(B))#endif #ifndef __HAVE_ARCH_PAGE_TEST_DIRTY
@@ -344,6 +410,10 @@ extern void untrack_pfn_vma(struct vm_ar unsigned long size);#endif +#ifndef CONFIG_TRANSPARENT_HUGEPAGE +#define pmd_write (pmd) 0 +#endif +#endif /* !__ASSEMBLY__ */ #endif /* _ASM_GENERIC_PGTABLE_H */
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 14 of 31] add pmd mangling generic functions
Quoted 6 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Some are needed to build but not actually used on archs not supporting transparent hugepages. Others like
pmdp_clear_flushare used by x86 too.Signed-off-by Andrea Arcangeli<[email protected]>
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 14 of 31] add pmd mangling generic functions
In reply to Andrea ArcangeliQuoted 5 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
Some are needed to build but not actually used on archs not supporting transparent hugepages. Others like
pmdp_clear_flushare used by x86 too.
If they are not used, why are they needed to build?
Quoted 130 lines
Signed-off-by Andrea Arcangeli <[email protected]>---
include/asm-generic/pgtable.h +70
-0@@ -23,6 +23,19 @@ } \ __changed; \ }) + +#define pmdp_set_access_flags (__vma, __address, __pmdp, __entry, __dirty) \ + ({ \ + int __changed = !pmd_same(*(__pmdp), __entry); \ + VM_BUG_ON((__address) & ~HPAGE_PMD_MASK); \ + if (__changed) { \ + set_pmd_at((__vma)->vm_mm, __address, __pmdp, \ + __entry); \ + flush_tlb_range(__vma, __address, \ + (__address) + HPAGE_PMD_SIZE); \ + } \ + __changed; \ + })#endif #ifndef __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG@@ -37,6 +50,17 @@ (__ptep), pte_mkold(__pte)); \ r; \ }) +#define pmdp_test_and_clear_young (__vma, __address, __pmdp) \ +({ \ + pmd_t __pmd = *(__pmdp); \ + int r = 1; \ + if (!pmd_young(__pmd)) \ + r = 0; \ + else \ + set_pmd_at((__vma)->vm_mm, (__address), \ + (__pmdp), pmd_mkold(__pmd)); \ + r; \ +})#endif #ifndef __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH@@ -48,6 +72,16 @@flush_tlb_page (__vma, __address); \ __young; \ }) +#define pmdp_clear_flush_young (__vma, __address, __pmdp) \ +({ \ + int __young; \ + VM_BUG_ON((__address) & ~HPAGE_PMD_MASK); \ + __young = pmdp_test_and_clear_young(__vma, __address, __pmdp); \ + if (__young) \ + flush_tlb_range(__vma, __address, \ + (__address) + HPAGE_PMD_SIZE); \ + __young; \ +})#endif #ifndef __HAVE_ARCH_PTEP_GET_AND_CLEAR@@ -57,6 +91,13 @@pte_clear ((__mm), (__address), (__ptep)); \ __pte; \ }) + +#define pmdp_get_and_clear (__mm, __address, __pmdp) \ +({ \ + pmd_t __pmd = *(__pmdp); \ + pmd_clear((__mm), (__address), (__pmdp)); \ + __pmd; \ +})#endif #ifndef __HAVE_ARCH_PTEP_GET_AND_CLEAR_FULL@@ -88,6 +129,15 @@ do { \flush_tlb_page (__vma, __address); \ __pte; \ }) + +#define pmdp_clear_flush (__vma, __address, __pmdp) \ +({ \ + pmd_t __pmd; \ + VM_BUG_ON((__address) & ~HPAGE_PMD_MASK); \ + __pmd = pmdp_get_and_clear((__vma)->vm_mm, __address, __pmdp); \ + flush_tlb_range(__vma, __address, (__address) + HPAGE_PMD_SIZE);\ + __pmd; \ +})#endif #ifndef __HAVE_ARCH_PTEP_SET_WRPROTECT@@ -97,10 +147,26 @@ static inline void ptep_set_wrprotect(stpte_t old_pte = *ptep;set_pte_at (mm, address, ptep,pte_wrprotect (old_pte)); } + +static inline void pmdp_set_wrprotect (struct mm_struct *mm,unsigned long address,pmd_t *pmdp) +{ +pmd_t old_pmd = *pmdp; +set_pmd_at (mm, address, pmdp,pmd_wrprotect (old_pmd)); +} + +#define pmdp_splitting_flush (__vma, __address, __pmdp) \ +({ \ + pmd_t __pmd = pmd_mksplitting(*(__pmdp)); \ + VM_BUG_ON((__address) & ~HPAGE_PMD_MASK); \ + set_pmd_at((__vma)->vm_mm, __address, __pmdp, __pmd); \ +/* tlb flush only to serialize against gup-fast */ \ +flush_tlb_range (__vma, __address, (__address) +HPAGE_PMD_SIZE );\ +})#endif #ifndef __HAVE_ARCH_PTE_SAME#define pte_same (A ,B ) (pte_val(A) == pte_val(B)) +#define pmd_same (A ,B ) (pmd_val(A) == pmd_val(B))#endif #ifndef __HAVE_ARCH_PAGE_TEST_DIRTY@@ -344,6 +410,10 @@ extern void untrack_pfn_vma(struct vm_ar unsigned long size);#endif +#ifndef CONFIG_TRANSPARENT_HUGEPAGE +#define pmd_write (pmd) 0 +#endif +#endif /* !__ASSEMBLY__ */ #endif /* _ASM_GENERIC_PGTABLE_H */
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 14 of 31] add pmd mangling generic functions
Quoted 8 lines · Mel Gorman
Quoted 5 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
Some are needed to build but not actually used on archs not supporting transparent hugepages. Others like
pmdp_clear_flushare used by x86 too.If they are not used, why are they needed to build?
Oh well I went extra mile in my last patchset. can re-review the new version? Maybe it builds on all archs too ;)
But I kept the pmd unused methods implemented as long as long as the pte counterpart existed. But I ensured the pmd methods defines to BUG() if TRANSPARENT_HUGEPAGE is null, to be 100% sure nobody uses them unless it is allowed to. It is needed to build because things like pmd_write are used in memory.c, but they have to be optimized away at compile time, so no actual BUG() bytecode should never hit kernel .text and especially BUG() will make sure it won't hit runtime in case it does...
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 pmd_trans_huge migrate bugcheck
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
No pmd_trans_huge should ever materialize in migration ptes areas, because we split the hugepage before migration ptes are instantiated.
---
include/linux/huge_mm.h +5 -0
@@ -107,6 +107,10 @@ static inline int PageTransHuge(struct pVM_BUG_ON (PageTail (page)); return PageHead(page); } +static inline int PageTransCompound (struct page *page) +{ +return PageCompound (page); +}#else /* CONFIG_TRANSPARENT_HUGEPAGE */ #define transparent_hugepage_enabled (__vma) 0#define transparent_hugepage_defrag (__vma) 0
@@ -124,6 +128,7 @@ static inline int split_huge_page(struct#define wait_split_huge_page (__anon_vma, __pmd) \ do { } while (0)#define PageTransHuge (page) 0 +#define PageTransCompound (page) 0static inline int hugepage_madvise (unsigned long *vm_flags) {BUG_ON (0 );
mm/migrate.c +5 -0
@@ -99,6 +99,7 @@ static int remove_migration_pte(struct p goto out; pmd =pmd_offset (pud, addr); +VM_BUG_ON (pmd_trans_huge (*pmd));if (!pmd_present (*pmd)) goto out;
@@ -819,6 +820,10 @@ static int do_move_page_to_node_array(stif (PageReserved (page) ||PageKsm (page)) goto put_and_set; +if (unlikely (PageTransCompound (page))) +if (unlikely (split_huge_page (page))) + goto put_and_set; + pp->page = page; err =page_to_nid (page);
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 27 of 31] pmd_trans_huge migrate bugcheck
Quoted 6 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
No
pmd_trans_hugeshould ever materialize in migration ptes areas, because we split the hugepage before migration ptes are instantiated.Signed-off-by Andrea Arcangeli<[email protected]>
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 no paravirt version of pmd ops
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
No paravirt version of set_pmd_at/pmd_update/pmd_update_defer.
---
arch/x86/include/asm/pgtable.h +3 -0
@@ -33,6 +33,7 @@ extern struct list_head pgd_list;#else /* !CONFIG_PARAVIRT */ #define set_pte (ptep, pte) native_set_pte(ptep, pte)#define set_pte_at (mm, addr, ptep, pte) native_set_pte_at(mm, addr, ptep, pte) +#define set_pmd_at (mm, addr, pmdp, pmd) native_set_pmd_at(mm, addr, pmdp, pmd)#define set_pte_atomic (ptep, pte) \ native_set_pte_atomic(ptep, pte)
@@ -57,6 +58,8 @@ extern struct list_head pgd_list;#define pte_update (mm, addr, ptep) do { } while (0)#define pte_update_defer (mm, addr, ptep) do { } while (0) +#define pmd_update (mm, addr, ptep) do { } while (0) +#define pmd_update_defer (mm, addr, ptep) do { } while (0)#define pgd_val (x) native_pgd_val(x)#define __pgd (x) native_make_pgd(x)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 09 of 31] no paravirt version of pmd ops
Quoted 5 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
No paravirt version of set_pmd_at/pmd_update/pmd_update_defer.
Signed-off-by Andrea Arcangeli<[email protected]>
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 09 of 31] no paravirt version of pmd ops
In reply to Andrea ArcangeliQuoted 5 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
No paravirt version of set_pmd_at/pmd_update/pmd_update_defer.
Signed-off-by Andrea Arcangeli <[email protected]>
Quoted 23 lines
---
arch/x86/include/asm/pgtable.h +3
-0@@ -33,6 +33,7 @@ extern struct list_head pgd_list;#else /* !CONFIG_PARAVIRT */ #define set_pte (ptep, pte) native_set_pte(ptep, pte)#define set_pte_at (mm, addr, ptep, pte) native_set_pte_at(mm, addr, ptep, pte) +#define set_pmd_at (mm, addr, pmdp, pmd) native_set_pmd_at(mm, addr, pmdp, pmd)#define set_pte_atomic (ptep, pte) \ native_set_pte_atomic(ptep, pte)@@ -57,6 +58,8 @@ extern struct list_head pgd_list;#define pte_update (mm, addr, ptep) do { } while (0)#define pte_update_defer (mm, addr, ptep) do { } while (0) +#define pmd_update (mm, addr, ptep) do { } while (0) +#define pmd_update_defer (mm, addr, ptep) do { } while (0)#define pgd_val (x) native_pgd_val(x)#define __pgd (x) native_make_pgd(x)
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 clear page compound
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
split_huge_page must transform a compound page to a regular page and needs ClearPageCompound.
---
include/linux/page-flags.h +16 -1
@@ -349,7 +349,7 @@ static inline void set_page_writeback(st* tests can be used in performance sensitive paths. PageCompound is * generally not used in hot code paths. */ -__PAGEFLAG(Head, head) +__PAGEFLAG(Head, head) CLEARPAGEFLAG(Head, head) __PAGEFLAG(Tail, tail)static inline int PageCompound (struct page *page)
@@ -357,6 +357,13 @@ static inline int PageCompound(struct pa return page->flags & ((1L << PG_head) | (1L << PG_tail)); } +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +static inline void ClearPageCompound (struct page *page) +{ +BUG_ON (!PageHead (page)); +ClearPageHead (page); +} +#endif #else /* * Reduce page flag use as much as possible by overlapping
@@ -394,6 +401,14 @@ static inline void __ClearPageTail(struc page->flags &= ~PG_head_tail_mask; } +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +static inline void ClearPageCompound (struct page *page) +{ +BUG_ON (page->flags & PG_head_tail_mask != (1L << PG_compound)); +ClearPageCompound (page); +} +#endif +#endif /* !PAGEFLAGS_EXTENDED */ #ifdef CONFIG_MMU
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 19 of 31] clear page compound
Quoted 6 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
split_huge_pagemust transform a compound page to a regular page and needs ClearPageCompound.Signed-off-by Andrea Arcangeli<[email protected]>
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 19 of 31] clear page compound
In reply to Andrea ArcangeliQuoted 35 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
split_huge_pagemust transform a compound page to a regular page and needs ClearPageCompound.Signed-off-by Andrea Arcangeli <[email protected]>---
include/linux/page-flags.h +8
-1@@ -349,7 +349,7 @@ static inline void set_page_writeback(st* tests can be used in performance sensitive paths. PageCompound is * generally not used in hot code paths. */ -__PAGEFLAG(Head, head) +__PAGEFLAG(Head, head) CLEARPAGEFLAG(Head, head) __PAGEFLAG(Tail, tail)static inline int PageCompound (struct page *page)@@ -357,6 +357,13 @@ static inline int PageCompound(struct pa return page->flags & ((1L << PG_head) | (1L << PG_tail)); } +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +static inline void ClearPageCompound (struct page *page) +{ +BUG_ON (!PageHead (page)); +ClearPageHead (page); +} +#endif #else /* * Reduce page flag use as much as possible by overlapping
include/linux/page-flags.h static inline void __ClearPageTail(struc · line 407
Quoted 7 lines
include/linux/page-flags.h +4
-0@@ -394,6 +401,14 @@ static inline void __ClearPageTail(struc page->flags &= ~PG_head_tail_mask; } +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +static inline void ClearPageCompound (struct page *page) +{ +BUG_ON (page->flags & PG_head_tail_mask != (1L << PG_compound));
1L?
Quoted 8 lines
include/linux/page-flags.h +4
-0+ClearPageCompound (page); +} +#endif +#endif /* !PAGEFLAGS_EXTENDED */ #ifdef CONFIG_MMU
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 19 of 31] clear page compound
Quoted 5 lines · Mel Gorman
include/linux/page-flags.h static inline void __ClearPageTail(struc · line 407
Quoted 3 lines
include/linux/page-flags.h +3
-0+static inline void ClearPageCompound (struct page *page) +{ +BUG_ON (page->flags & PG_head_tail_mask != (1L << PG_compound));1L?
cleaned up.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 config_transparent_hugepage
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Add config option.
---
mm/Kconfig +14 -0
@@ -283,3 +283,17 @@ config NOMMU_INITIAL_TRIM_EXCESS of 1 says that all excess pages should be trimmed. See Documentation/nommu-mmap.txt for more information. + +config TRANSPARENT_HUGEPAGE + bool "Transparent Hugepage support" if EMBEDDED + depends on X86_64 + default y + help + Transparent Hugepages allows the kernel to use huge pages and + huge tlb transparently to the applications whenever possible. + This feature can improve computing performance to certain + applications by speeding up page faults during memory + allocation, by reducing the number of tlb misses and by speeding + up the pagetable walking. + + If memory constrained on embedded, you may want to say N.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 12 of 31] config_transparent_hugepage
Quoted 5 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Add config option.
Signed-off-by Andrea Arcangeli<[email protected]>
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 12 of 31] config_transparent_hugepage
In reply to Andrea ArcangeliQuoted 11 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
Add config option.
Signed-off-by Andrea Arcangeli <[email protected]>---
mm/Kconfig config NOMMU_INITIAL_TRIM_EXCESS · line 290
Quoted 8 lines
mm/Kconfig +5
-0@@ -283,3 +283,17 @@ config NOMMU_INITIAL_TRIM_EXCESS of 1 says that all excess pages should be trimmed. See Documentation/nommu-mmap.txt for more information. + +config TRANSPARENT_HUGEPAGE + bool "Transparent Hugepage support" if EMBEDDED + depends on X86_64 + default y
Are there embedded x86-64 boxen? I'm surprised it's not a normal option and is selected by default but don't have a problem with it as such.
Quoted 10 lines
mm/Kconfig +9
-0+ help + Transparent Hugepages allows the kernel to use huge pages and + huge tlb transparently to the applications whenever possible. + This feature can improve computing performance to certain + applications by speeding up page faults during memory + allocation, by reducing the number of tlb misses and by speeding + up the pagetable walking. + + If memory constrained on embedded, you may want to say N.
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 12 of 31] config_transparent_hugepage
Quoted 1 line · Mel Gorman
Are there embedded x86-64 boxen? I'm surprised it's not a normal option
atom 200 4w TDP 64bit, atom 300 8 W 64bit. For some apps atom might be enough (not for my embedded usages though, my carpc is core 2 duo).
Quoted 1 line
and is selected by default but don't have a problem with it as such.
It's possible to disable on embedded to save a few kbytes of .text if they're not using the feature.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 12 of 31] config_transparent_hugepage
Quoted 11 lines · Andrea Arcangeli
Quoted 1 line · Mel Gorman
Are there embedded x86-64 boxen? I'm surprised it's not a normal option
atom 200 4w TDP 64bit, atom 300 8 W 64bit. For some apps atom might be enough (not for my embedded usages though, my carpc is core 2 duo).
Quoted 1 line
and is selected by default but don't have a problem with it as such.
It's possible to disable on embedded to save a few kbytes of .text if they're not using the feature.
Ok, seems sensible. Atom should have sprung to mind but it didn't.
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 define MADV_HUGEPAGE
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Define MADV_HUGEPAGE.
---
include/asm-generic/mman-common.h +2 -0
@@ -45,6 +45,8 @@#define MADV_MERGEABLE 12/* KSM may merge identical pages */ #define MADV_UNMERGEABLE 13/* KSM may not merge identical pages */ +#define MADV_HUGEPAGE 15/* Worth backing with hugepages */ +/* compatibility flags */ #define MAP_FILE 0
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 01 of 31] define MADV_HUGEPAGE
Quoted 5 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Define
MADV_HUGEPAGE.Signed-off-by Andrea Arcangeli<[email protected]>
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 01 of 31] define MADV_HUGEPAGE
In reply to Andrea ArcangeliQuoted 5 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
Define
MADV_HUGEPAGE.Signed-off-by Andrea Arcangeli <[email protected]>
Quoted 15 lines
---
include/asm-generic/mman-common.h +2
-0@@ -45,6 +45,8 @@#define MADV_MERGEABLE 12/* KSM may merge identical pages */ #define MADV_UNMERGEABLE 13/* KSM may not merge identical pages */ +#define MADV_HUGEPAGE 15/* Worth backing with hugepages */ +/* compatibility flags */ #define MAP_FILE 0
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 01 of 31] define MADV_HUGEPAGE
In reply to Andrea ArcangeliQuoted 11 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
Define
MADV_HUGEPAGE.Signed-off-by Andrea Arcangeli <[email protected]>---
include/asm-generic/mman-common.h line 51
Quoted 7 lines
include/asm-generic/mman-common.h +2
-0@@ -45,6 +45,8 @@#define MADV_MERGEABLE 12/* KSM may merge identical pages */ #define MADV_UNMERGEABLE 13/* KSM may not merge identical pages */ +#define MADV_HUGEPAGE 15/* Worth backing with hugepages */ +/* compatibility flags */ #define MAP_FILE 0
It embarrasses me to find the time to comment on so trivial a patch, and none more interesting; but I have to say that I don't think this patch can be right - in two ways.
You moved MADV_HUGEPAGE from 14 to 15 because someone noticed #define MADV_16K_PAGES 14 in arch/parisc/include/asm/mman.h?
Well, if we need to respect that, then we ought to respect its /* The range 12-64 is reserved for page size specification. */:
15 would be intended for 32K pages.
I don't know why parisc (even as far back as 2.4.0) wants those
definitions: I guess to allow some peculiar-to-parisc program to build on Linux, yet fail with EINVAL when it runs? I rather think they should never have been added (and perhaps could even be removed).
But, whether 14 or 15 or something else, I expect you're preventing mm/madvise.c from building on alpha, mips, parisc and xtensa. Those arches don't include asm-generic/mman-common.h, because of various divergencies, of which MADV_16K_PAGES would be just one.
So I think you should follow what we did with MADV_MERGEABLE:
define it in asm-generic/mman-common.h and the four arches, use the expected number 14 wherever you can, and 67 for parisc.
Or if you feel there's virtue in using the same number on all arches (it would be less confusing, yes) and want to pave that way (as we'd have better done with MADV_MERGEABLE), add a comment into four of those files to point to parisc's peculiar group, and use the same number 67 on all (perhaps via an asm-generic/madv-common.h).
I'd take the lazy way out and follow what we did with MADV_MERGEABLE, unless Arnd (Mr Asm-Generic) would prefer something else.
Hugh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 01 of 31] define MADV_HUGEPAGE
Quoted 6 lines · Hugh Dickins
It embarrasses me to find the time to comment on so trivial a patch, and none more interesting; but I have to say that I don't think this patch can be right - in two ways.
You moved
MADV_HUGEPAGEfrom 14 to 15 because someone noticed #defineMADV_16K_PAGES14 inarch/parisc/include/asm/mman.h?
Correct.
Quoted 3 lines
Well, if we need to respect that, then we ought to respect its /* The range 12-64 is reserved for page size specification. */:
15 would be intended for 32K pages.
It would be probably better if those were defined with #define MADV_ instead of a comment that won't showup on my grep... I checked with grep across all archs and nothing showed up.
Quoted 15 lines
I don't know why parisc (even as far back as 2.4.0) wants those
definitions: I guess to allow some peculiar-to-parisc program to build on Linux, yet fail with EINVAL when it runs? I rather think they should never have been added (and perhaps could even be removed).But, whether 14 or 15 or something else, I expect you're preventing
mm/madvise.cfrom building on alpha, mips, parisc and xtensa. Those arches don't includeasm-generic/mman-common.h, because of various divergencies, of whichMADV_16K_PAGESwould be just one.So I think you should follow what we did with
MADV_MERGEABLE:
define it inasm-generic/mman-common.hand the four arches, use the expected number 14 wherever you can, and 67 for parisc.
Quoted 8 lines
Or if you feel there's virtue in using the same number on all arches (it would be less confusing, yes) and want to pave that way (as we'd have better done with
MADV_MERGEABLE), add a comment into four of those files to point to parisc's peculiar group, and use the same number 67 on all (perhaps via anasm-generic/madv-common.h).I'd take the lazy way out and follow what we did with
MADV_MERGEABLE, unless Arnd (Mr Asm-Generic) would prefer something else.
I've no problem to do the not-lazy way of madv-common.h, and yes I think it's less confusing to have one number for all archs...
Let's say, to me the important thing is we agree on one number, and that MADV_HUGEPAGE is useful for embedded that may want to turn off transparent hugepage feature except on a few mappings (to avoids risking to lose minor memory during cows).
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 01 of 31] define MADV_HUGEPAGE
Quoted 5 lines · Andrea Arcangeli
I've no problem to do the not-lazy way of
madv-common.h, and yes I think it's less confusing to have one number for all archs...Let's say, to me the important thing is we agree on one number,
It is important to stabilize on a number, instead of having it shift from one version of the patchset to another; but I don't think it's important that the same number be used on every architecture.
Hugh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 01 of 31] define MADV_HUGEPAGE
In reply to Hugh DickinsQuoted 47 lines · Hugh Dickins
Quoted 11 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
Define
MADV_HUGEPAGE.Signed-off-by Andrea Arcangeli <[email protected]>---
include/asm-generic/mman-common.h line 51
Quoted 7 lines
include/asm-generic/mman-common.h +2
-0@@ -45,6 +45,8 @@ #define MADV_MERGEABLE 12 /* KSM may merge identical pages */ #define MADV_UNMERGEABLE 13 /* KSM may not merge identical pages */ +#define MADV_HUGEPAGE 15/* Worth backing with hugepages */ + /* compatibility flags */ #define MAP_FILE 0It embarrasses me to find the time to comment on so trivial a patch, and none more interesting; but I have to say that I don't think this patch can be right - in two ways.
You moved
MADV_HUGEPAGEfrom 14 to 15 because someone noticed #defineMADV_16K_PAGES14 inarch/parisc/include/asm/mman.h?Well, if we need to respect that, then we ought to respect its /* The range 12-64 is reserved for page size specification. */:
15 would be intended for 32K pages.I don't know why parisc (even as far back as 2.4.0) wants those
definitions: I guess to allow some peculiar-to-parisc program to build on Linux, yet fail with EINVAL when it runs? I rather think they should never have been added (and perhaps could even be removed).But, whether 14 or 15 or something else, I expect you're preventing
mm/madvise.cfrom building on alpha, mips, parisc and xtensa. Those arches don't includeasm-generic/mman-common.h, because of various divergencies, of whichMADV_16K_PAGESwould be just one.So I think you should follow what we did with
MADV_MERGEABLE:
define it inasm-generic/mman-common.hand the four arches, use the expected number 14 wherever you can, and 67 for parisc.
Quoted 8 lines
Or if you feel there's virtue in using the same number on all arches (it would be less confusing, yes) and want to pave that way (as we'd have better done with
MADV_MERGEABLE), add a comment into four of those files to point to parisc's peculiar group, and use the same number 67 on all (perhaps via anasm-generic/madv-common.h).I'd take the lazy way out and follow what we did with
MADV_MERGEABLE, unless Arnd (Mr Asm-Generic) would prefer something else.
Hey, lets bring some PARISC people to the party! Maybe MADV_16K_PAGES can be fixed in a nice way?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Arnd Bergmann
maintainerRe: [PATCH 01 of 31] define MADV_HUGEPAGE
In reply to Hugh DickinsQuoted 4 lines · Hugh Dickins
So I think you should follow what we did with
MADV_MERGEABLE:
define it inasm-generic/mman-common.hand the four arches, use the expected number 14 wherever you can, and 67 for parisc.
Quoted 8 lines
Or if you feel there's virtue in using the same number on all arches (it would be less confusing, yes) and want to pave that way (as we'd have better done with
MADV_MERGEABLE), add a comment into four of those files to point to parisc's peculiar group, and use the same number 67 on all (perhaps via anasm-generic/madv-common.h).I'd take the lazy way out and follow what we did with
MADV_MERGEABLE, unless Arnd (Mr Asm-Generic) would prefer something else.
I fully agree with using 14 in asm-generic and 67 in parisc.
Arnd
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
PATCH 1/1 alter compound get_page/put_page
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Alter compound get_page/put_page to keep references on subpages too, in order to allow __split_huge_page_refcount to split an hugepage even while subpages have been pinned by one of the get_user_pages() variants.
---
arch/powerpc/mm/gup.c +8 -0
@@ -47,6 +47,14 @@ static noinline int gup_pte_range(pmd_tput_page (page);return 0 ; } +if (PageTail (page)) { +/* +* __split_huge_page_refcount() cannot run +* from under us. +*/ +VM_BUG_ON (atomic_read (&page->_count) <0 ); +atomic_inc (&page->_count); + } pages[*nr] = page; (*nr)++;
arch/x86/mm/gup.c +8 -0
@@ -128,6 +128,14 @@ static noinline int gup_huge_pmd(pmd_t p do { VM_BUG_ON(compound_head(page) != head); pages[*nr] = page; + if (PageTail(page)) { + /* + * __split_huge_page_refcount() cannot run + * from under us. + */ + VM_BUG_ON(atomic_read(&page->_count) < 0); + atomic_inc(&page->_count); + } (*nr)++; page++; refs++;
include/linux/mm.h +14 -2
@@ -297,12 +297,16 @@ static inline int is_vmalloc_or_module_astatic inline void compound_lock (struct page *page) { +#ifdef CONFIG_TRANSPARENT_HUGEPAGE bit_spin_lock (PG_compound_lock, &page->flags); +#endif }static inline void compound_unlock (struct page *page) { +#ifdef CONFIG_TRANSPARENT_HUGEPAGE bit_spin_unlock (PG_compound_lock, &page->flags); +#endif }static inline struct page *compound_head (struct page *page)
@@ -319,9 +323,17 @@ static inline int page_count(struct pagestatic inline void get_page (struct page *page) { - page =compound_head (page); -VM_BUG_ON (atomic_read (&page->_count) ==0 ); +VM_BUG_ON (atomic_read (&page->_count) < !PageTail (page));atomic_inc (&page->_count); +if (unlikely (PageTail (page))) { +/* +* This is safe only because +* __split_huge_page_refcount can't run under +* get_page(). +*/ +VM_BUG_ON (atomic_read (&page->first_page->_count) <=0 ); +atomic_inc (&page->first_page->_count); + } }static inline struct page *virt_to_head_page (const void *x)
include/linux/page-flags.h +10 -1
@@ -108,7 +108,9 @@ enum pageflags {#ifdef CONFIG_MEMORY_FAILURE PG_hwpoison, /* hardware poisoned page. Don't touch */#endif +#ifdef CONFIG_TRANSPARENT_HUGEPAGE PG_compound_lock, +#endif __NR_PAGEFLAGS,/* Filesystems */
@@ -400,6 +402,12 @@ static inline void __ClearPageTail(struc#define __PG_MLOCKED 0#endif +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +#define __PG_COMPOUND_LOCK (1 << PG_compound_lock) +#else +#define __PG_COMPOUND_LOCK 0 +#endif +/* * Flags checked when a page is freed. Pages being freed should not have * these flags set. It they are, there is a problem.
@@ -409,7 +417,8 @@ static inline void __ClearPageTail(struc1 << PG_private |1 << PG_private_2 | \1 << PG_buddy |1 << PG_writeback |1 << PG_reserved | \1 << PG_slab |1 << PG_swapcache |1 << PG_active | \ - 1 << PG_unevictable | __PG_MLOCKED | __PG_HWPOISON) +1 << PG_unevictable | __PG_MLOCKED | __PG_HWPOISON | \ + 1 << __PG_COMPOUND_LOCK)/* * Flags checked when a page is prepped for return by the page allocator.
mm/swap.c +72 -7
96 lines not on this page · raw message
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 03 of 31] alter compound get_page/put_page
Quoted 7 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Alter compound get_page/put_page to keep references on subpages too, in order to allow
__split_huge_page_refcountto split an hugepage even while subpages have been pinned by one of theget_user_pages()variants.Signed-off-by Andrea Arcangeli<[email protected]>
Ahh, I see you added the #ifdef in this patch.
Signature · 7 lines
All rights reversed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 03 of 31] alter compound get_page/put_page
Quoted 1 line · Rik van Riel
Ahh, I see you added the #ifdef in this patch.
Yep, or x86 wouldn't build because there wasn't enough space in page-flags. #7 should build on all archs including i386. I guess I should have folded the changes in the previous patch like said in previous email, I'll clean it up now, end result is the same.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 03 of 31] alter compound get_page/put_page
Quoted 7 lines · Andrea Arcangeli
Quoted 1 line · Rik van Riel
Ahh, I see you added the #ifdef in this patch.
Yep, or x86 wouldn't build because there wasn't enough space in page-flags. #7 should build on all archs including i386. I guess I should have folded the changes in the previous patch like said in previous email, I'll clean it up now, end result is the same.
Sounds good.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 03 of 31] alter compound get_page/put_page
In reply to Andrea ArcangeliQuoted 14 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
Alter compound get_page/put_page to keep references on subpages too, in order to allow
__split_huge_page_refcountto split an hugepage even while subpages have been pinned by one of theget_user_pages()variants.Signed-off-by Andrea Arcangeli <[email protected]>---
arch/powerpc/mm/gup.c +0
-0@@ -47,6 +47,14 @@ static noinline int gup_pte_range(pmd_tput_page (page);
arch/powerpc/mm/gup.c static noinline int gup_pte_range(pmd_t · line 57
Quoted 10 lines
arch/powerpc/mm/gup.c +8
-0return 0 ; } +if (PageTail (page)) { +/* +* __split_huge_page_refcount() cannot run +* from under us. +*/ +VM_BUG_ON (atomic_read (&page->_count) <0 ); +atomic_inc (&page->_count); + }
Is it worth considering making some of these VM_BUG_ON's BUG_ON's? None of them will trigger in production setups. While you have tested heavily on your own machines, there might be some wacky corner case. I know the downside is two atomics in there instead of one in there but it might be worth it for a year anyway.
Also, Dave had suggested making this a helper in a previous revision to avoid duplicating the comment if nothing else. It wouldn't hurt.
Quoted 88 lines
arch/powerpc/mm/gup.c +0
-0pages[*nr] = page; (*nr)++;arch/x86/mm/gup.c +8
-0@@ -128,6 +128,14 @@ static noinline int gup_huge_pmd(pmd_t p do { VM_BUG_ON(compound_head(page) != head); pages[*nr] = page; + if (PageTail(page)) { + /* + * __split_huge_page_refcount() cannot run + * from under us. + */ + VM_BUG_ON(atomic_read(&page->_count) < 0); + atomic_inc(&page->_count); + } (*nr)++; page++; refs++;include/linux/mm.h +14
-2@@ -297,12 +297,16 @@ static inline int is_vmalloc_or_module_astatic inline void compound_lock (struct page *page) { +#ifdef CONFIG_TRANSPARENT_HUGEPAGE bit_spin_lock (PG_compound_lock, &page->flags); +#endif }static inline void compound_unlock (struct page *page) { +#ifdef CONFIG_TRANSPARENT_HUGEPAGE bit_spin_unlock (PG_compound_lock, &page->flags); +#endif }static inline struct page *compound_head (struct page *page)@@ -319,9 +323,17 @@ static inline int page_count(struct pagestatic inline void get_page (struct page *page) { - page =compound_head (page); -VM_BUG_ON (atomic_read (&page->_count) ==0 ); +VM_BUG_ON (atomic_read (&page->_count) < !PageTail (page));atomic_inc (&page->_count); +if (unlikely (PageTail (page))) { +/* +* This is safe only because +* __split_huge_page_refcount can't run under +* get_page(). +*/ +VM_BUG_ON (atomic_read (&page->first_page->_count) <=0 ); +atomic_inc (&page->first_page->_count); + } }static inline struct page *virt_to_head_page (const void *x)include/linux/page-flags.h +8
-0@@ -108,7 +108,9 @@ enum pageflags {#ifdef CONFIG_MEMORY_FAILURE PG_hwpoison, /* hardware poisoned page. Don't touch */#endif +#ifdef CONFIG_TRANSPARENT_HUGEPAGE PG_compound_lock, +#endif __NR_PAGEFLAGS,/* Filesystems */ @@ -400,6 +402,12 @@ static inline void __ClearPageTail(struc#define __PG_MLOCKED 0#endif +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +#define __PG_COMPOUND_LOCK (1 << PG_compound_lock) +#else +#define __PG_COMPOUND_LOCK 0 +#endif +/* * Flags checked when a page is freed. Pages being freed should not have * these flags set. It they are, there is a problem.
include/linux/page-flags.h static inline void __ClearPageTail(struc · line 421
Quoted 6 lines
include/linux/page-flags.h +2
-1@@ -409,7 +417,8 @@ static inline void __ClearPageTail(struc1 << PG_private |1 << PG_private_2 | \1 << PG_buddy |1 << PG_writeback |1 << PG_reserved | \1 << PG_slab |1 << PG_swapcache |1 << PG_active | \ - 1 << PG_unevictable | __PG_MLOCKED | __PG_HWPOISON) +1 << PG_unevictable | __PG_MLOCKED | __PG_HWPOISON | \ + 1 << __PG_COMPOUND_LOCK)
#define __PG_COMPOUND_LOCK (1 << PG_compound_lock)
and 1 << __PG_COMPOUND_LOCK
so __PG_COMPOUND_LOCK is already shifted. Is that intentional? Unless I am missing something obvious, it looks like it should be
+ 1 << PG_unevictable | __PG_MLOCKED | __PG_HWPOISON | \
+ __PG_COMPOUND_LOCK)
If it is not intentional, it should be harmless at runtime because the impact is not checking a flag is properly clear.
Quoted 29 lines
include/linux/page-flags.h +0
-0/* * Flags checked when a page is prepped for return by the page allocator. mm/swap.c +14
-0@@ -55,17 +55,82 @@ static void __page_cache_release(structdel_page_from_lru (zone, page);spin_unlock_irqrestore (&zone->lru_lock, flags); } +} + +static void __put_single_page (struct page *page) +{ +__page_cache_release (page);free_hot_page (page); } +static void __put_compound_page (struct page *page) +{ +compound_page_dtor *dtor; + +__page_cache_release (page); + dtor =get_compound_page_dtor (page); + (*dtor)(page); +} +static void put_compound_page (struct page *page) {
mm/swap.c static void __page_cache_release(struct · line 80
Quoted 10 lines
mm/swap.c +4
-6- page =compound_head (page); -if (put_page_testzero (page)) { -compound_page_dtor *dtor; - - dtor =get_compound_page_dtor (page); - (*dtor)(page); +if (unlikely (PageTail (page))) { +/* __split_huge_page_refcount can run under us */ +struct page *page_head = page->first_page; +smp_rmb ();
Can you explain why the barrier is needed and why this is sufficient? It looks like you are checking for races before compound_lock() is called but I'm not seeing how the window is fully closed if that is the case.
Quoted 66 lines
mm/swap.c +54
-1+if (likely (PageTail (page) &&get_page_unless_zero (page_head))) { +if (unlikely (!PageHead (page_head))) { +/* PageHead is cleared after PageTail */ +smp_rmb (); +VM_BUG_ON (PageTail (page)); + goto out_put_head; + } +/* +* Only run compound_lock on a valid PageHead, +* after having it pinned with +* get_page_unless_zero() above. +*/ +smp_mb (); +/* page_head wasn't a dangling pointer */ +compound_lock (page_head); +if (unlikely (!PageTail (page))) { +/* __split_huge_page_refcount run before us */ +compound_unlock (page_head); +VM_BUG_ON (PageHead (page_head)); + out_put_head: +if (put_page_testzero (page_head)) +__put_single_page (page_head); + out_put_single: +if (put_page_testzero (page)) +__put_single_page (page); +return ; + } +VM_BUG_ON (page_head != page->first_page); +/* +* We can release the refcount taken by +* get_page_unless_zero now that +* split_huge_page_refcount is blocked on the +* compound_lock. +*/ +if (put_page_testzero (page_head)) +VM_BUG_ON (1 ); +/* __split_huge_page_refcount will wait now */ +VM_BUG_ON (atomic_read (&page->_count) <=0 ); +atomic_dec (&page->_count); +VM_BUG_ON (atomic_read (&page_head->_count) <=0 ); +compound_unlock (page_head); +if (put_page_testzero (page_head)) +__put_compound_page (page_head); + }else { +/* page_head is a dangling pointer */ +VM_BUG_ON (PageTail (page)); + goto out_put_single; + } + }else if (put_page_testzero (page)) { +if (PageHead (page)) +__put_compound_page (page); +else +__put_single_page (page); } }@@ -74,7 +139,7 @@ void put_page(struct page *page)if (unlikely (PageCompound (page)))put_compound_page (page);else if (put_page_testzero (page)) -__page_cache_release (page); +__put_single_page (page); }EXPORT_SYMBOL (put_page);
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 03 of 31] alter compound get_page/put_page
Quoted 13 lines · Mel Gorman
Quoted 13 lines
arch/powerpc/mm/gup.c +6
-0@@ -47,6 +47,14 @@ static noinline int gup_pte_range(pmd_tput_page (page);return 0 ; } +if (PageTail (page)) { +/* +* __split_huge_page_refcount() cannot run +* from under us. +*/ +VM_BUG_ON (atomic_read (&page->_count) <0 );
Quoted 8 lines
arch/powerpc/mm/gup.c static noinline int gup_pte_range(pmd_t · line 57
Quoted 2 lines
arch/powerpc/mm/gup.c +2
-0+atomic_inc (&page->_count); + }Is it worth considering making some of these VM_BUG_ON's BUG_ON's? None of them will trigger in production setups. While you have tested heavily on your own machines, there might be some wacky corner case. I know the downside is two atomics in there instead of one in there but it might be worth it for a year anyway.
atomic_read isn't atomic. But it's also a fast path so I wouldn't like to have that... if things go under split_huge_page or free_pages_ok will cry I think, later, so it shouldn't go unnoticed.
Quoted 2 lines
Also, Dave had suggested making this a helper in a previous revision to avoid duplicating the comment if nothing else. It wouldn't hurt.
Ok! It must have been obfuscated by more urgent issues... thanks for the reminder!
Quoted 4 lines
#define
__PG_COMPOUND_LOCK(1 <<PG_compound_lock)and 1 <<
__PG_COMPOUND_LOCK
Quoted 8 lines
so
__PG_COMPOUND_LOCKis already shifted. Is that intentional? Unless I am missing something obvious, it looks like it should be+ 1 <<
PG_unevictable|__PG_MLOCKED|__PG_HWPOISON| \
+__PG_COMPOUND_LOCK)If it is not intentional, it should be harmless at runtime because the impact is not checking a flag is properly clear.
Correct.
Quoted 6 lines
Quoted 6 lines
arch/powerpc/mm/gup.c +0
-4static void put_compound_page (struct page *page) { - page =compound_head (page); -if (put_page_testzero (page)) { -compound_page_dtor *dtor; -
Quoted 8 lines
arch/powerpc/mm/gup.c
Quoted 6 lines
arch/powerpc/mm/gup.c +4
-2- dtor =get_compound_page_dtor (page); - (*dtor)(page); +if (unlikely (PageTail (page))) { +/* __split_huge_page_refcount can run under us */ +struct page *page_head = page->first_page; +smp_rmb ();Can you explain why the barrier is needed and why this is sufficient? It
smp_rmb is needed to be sure we read a first_page from a tail page. If it wasn't a tail page no more, while we read first_page, it wouldn't be safe.
Quoted 2 lines
looks like you are checking for races before
compound_lock()is called but I'm not seeing how the window is fully closed if that is the case.
I need to be sure I'm getting a real valid head_page before I can run compound_lock, so the above smp_rmb with the smb_wmb before overwriting first_page in split_huge_page is meant to guarantee it.
In futex it's the same, except there I disabled irqs as it's simpler and gup-fast accesses are all already in l1.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Re: [PATCH 03 of 31] alter compound get_page/put_page
Quoted 23 lines · Andrea Arcangeli
Quoted 13 lines · Mel Gorman
Quoted 13 lines
arch/powerpc/mm/gup.c +6
-0@@ -47,6 +47,14 @@ static noinline int gup_pte_range(pmd_tput_page (page);return 0 ; } +if (PageTail (page)) { +/* +* __split_huge_page_refcount() cannot run +* from under us. +*/ +VM_BUG_ON (atomic_read (&page->_count) <0 );Quoted 8 lines
arch/powerpc/mm/gup.c static noinline int gup_pte_range(pmd_t · line 57
Quoted 2 lines
arch/powerpc/mm/gup.c +2
-0+atomic_inc (&page->_count); + }Is it worth considering making some of these VM_BUG_ON's BUG_ON's? None of them will trigger in production setups. While you have tested heavily on your own machines, there might be some wacky corner case. I know the downside is two atomics in there instead of one in there but it might be worth it for a year anyway.
Quoted 4 lines
atomic_readisn't atomic. But it's also a fast path so I wouldn't like to have that... if things go undersplit_huge_pageorfree_pages_okwill cry I think, later, so it shouldn't go unnoticed.
Ok, if it's eventually caught anyway, then it's fine. At worst, the root cause of the error will be a little tricky to spot.
Quoted 6 lines
Quoted 2 lines
Also, Dave had suggested making this a helper in a previous revision to avoid duplicating the comment if nothing else. It wouldn't hurt.
Ok! It must have been obfuscated by more urgent issues... thanks for the reminder!
Yes, it was not exactly of earth-shattering importance :)
Quoted 34 lines
Quoted 4 lines
#define
__PG_COMPOUND_LOCK(1 <<PG_compound_lock)and 1 <<
__PG_COMPOUND_LOCKQuoted 8 lines
so
__PG_COMPOUND_LOCKis already shifted. Is that intentional? Unless I am missing something obvious, it looks like it should be+ 1 <<
PG_unevictable|__PG_MLOCKED|__PG_HWPOISON| \
+__PG_COMPOUND_LOCK)If it is not intentional, it should be harmless at runtime because the impact is not checking a flag is properly clear.
Correct.
Quoted 6 lines
Quoted 6 lines
arch/powerpc/mm/gup.c +0
-4static void put_compound_page (struct page *page) { - page =compound_head (page); -if (put_page_testzero (page)) { -compound_page_dtor *dtor; -Quoted 8 lines
arch/powerpc/mm/gup.c
Quoted 6 lines
arch/powerpc/mm/gup.c +4
-2- dtor =get_compound_page_dtor (page); - (*dtor)(page); +if (unlikely (PageTail (page))) { +/* __split_huge_page_refcount can run under us */ +struct page *page_head = page->first_page; +smp_rmb ();Can you explain why the barrier is needed and why this is sufficient? It
smp_rmbis needed to be sure we read afirst_pagefrom a tail page. If it wasn't a tail page no more, while we readfirst_page, it wouldn't be safe.
Quoted 7 lines
Quoted 2 lines
looks like you are checking for races before
compound_lock()is called but I'm not seeing how the window is fully closed if that is the case.I need to be sure I'm getting a real valid
head_pagebefore I can runcompound_lock, so the abovesmp_rmbwith thesmb_wmbbefore overwritingfirst_pageinsplit_huge_pageis meant to guarantee it.
Ah, now it's clearer when I can see the rmb/wmb pairing.
Quoted 3 lines
In futex it's the same, except there I disabled irqs as it's simpler and gup-fast accesses are all already in l1.
Thanks for the explanation.
Signature · 9 lines
Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
So I applied this patchset (got it here:
http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.6/2.6.33-rc5/transparent_hugepage-7/)
on top of 2.6.33-rc5 and got this on boot:
[ 16.484060] BUG: unable to handle kernel paging request at ffffea0002df0738 [ 16.485027] IP: [<ffffffff810ec0ac>] khugepaged+0x381/0xb3d [ 16.485027] PGD 2080067 PUD 2081067 PMD 0 [ 16.485027] Oops: 0000 [#1] PREEMPT SMP [ 16.485027] last sysfs file: /sys/class/firmware/timeout [ 16.485027] CPU 1 [ 16.485027] Pid: 580, comm: khugepaged Not tainted 2.6.33-rc5-aa #38 2241B48/2241B48 [ 16.485027] RIP: 0010:[<ffffffff810ec0ac>] [<ffffffff810ec0ac>] khugepaged+0x381/0xb3d [ 16.485027] RSP: 0000:ffff88007aefde10 EFLAGS: 00010282 [ 16.485027] RAX: ffffea0002df0738 RBX: 0000000000000dc0 RCX: ffff880079e71480 [ 16.485027] RDX: ffffea0000000000 RSI: 0000000000000001 RDI: ffff880079e72000 [ 16.485027] RBP: ffff88007aefdee0 R08: 0000000000000200 R09: ffff88007c379100 [ 16.485027] R10: 0000000000000020 R11: 0000000000000020 R12: 0000000000000018 [ 16.485027] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 16.485027] FS: 0000000000000000(0000) GS:ffff880001e80000(0000) knlGS:0000000000000000 [ 16.485027] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 16.485027] CR2: ffffea0002df0738 CR3: 0000000001a08000 CR4: 00000000000006e0 [ 16.485027] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 16.485027] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 16.485027] Process khugepaged (pid: 580, threadinfo ffff88007aefc000, task ffff88007aef43e0) [ 16.485027] Stack: [ 16.485027] ffff88007aefdee0 0000200000002000 0000042200000001 ffff88007abe4d10 [ 16.485027] <0> ffff880079e489c0 ffff880079ece000 ffff880079e48a20 00000000f7000000 [ 16.485027] <0> ffff88007aefc000 0000000000013cc0 ffff880079e48a38 ffff88007c3a16a0 [ 16.485027] Call Trace: [ 16.485027] [<ffffffff8105cc98>] ? autoremove_wake_function+0x0/0x38 [ 16.485027] [<ffffffff815e2fa3>] ? _raw_spin_unlock_irqrestore+0x25/0x30 [ 16.485027] [<ffffffff810ebd2b>] ? khugepaged+0x0/0xb3d [ 16.485027] [<ffffffff8105c7c2>] kthread+0x7d/0x85 [ 16.485027] [<ffffffff81003894>] kernel_thread_helper+0x4/0x10 [ 16.485027] [<ffffffff8105c745>] ? kthread+0x0/0x85 [ 16.485027] [<ffffffff81003890>] ? kernel_thread_helper+0x0/0x10 [ 16.485027] Code: 20 ba 01 00 00 00 0f 45 f2 48 ba 00 f0 ff ff ff 3f 00 00 48 21 d0 48 ba 00 00 00 00 00 ea ff ff 48 c1 e8 0c 48 6b c0 38 48 01 d0 <48> 8b 10 f6 c2 20 0f 84 b6 04 00 00 f6 c2 01 0f 85 ad 04 00 00 [ 16.485027] RIP [<ffffffff810ec0ac>] khugepaged+0x381/0xb3d [ 16.485027] RSP <ffff88007aefde10> [ 16.485027] CR2: ffffea0002df0738 [ 16.485027] ---[ end trace d42a4bb81928b65f ]---
addr2line tells me it is here:mm/huge_memory.o khugepaged + 0x381 = 0xbcc
/scm/linux-2.6/mm/huge_memory.c:1543constant_test_bit():
/scm/linux-2.6/arch/x86/include/asm/bitops.h:311
bcc: 48 8b 10 mov (%rax),%rdx
and code looks like this:
1536 for (_pte = pte; _pte < pte+HPAGE_PMD_NR; _pte++) {
1537 pte_t pteval = *_pte; 1538 barrier(); /* read from memory */ 1539 if (!pte_present(pteval) || !pte_write(pteval)) 1540 goto out_unmap; 1541 if (pte_young(pteval)) 1542 referenced = 1; 1543 page = pte_page(pteval); 1544 VM_BUG_ON(PageCompound(page)); 1545 if (!PageLRU(page) || PageLocked(page) || !PageAnon(page))
1546 goto out_unmap;
1547 /* cannot use mapcount: can't collapse if there's a gup pin */
1548 if (page_count(page) != 1)
1549 goto out_unmap;
1550 }
Got to go, hope this helps.
Signature · 7 lines
MST -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Hi Michael,
Please try again booting with transparent_hugepage=5 that will disable khugepaged, it'll still provide a benefit to you, it should avoid the problem, and in meantime, I'll send you a debug patch to see exactly what's inside that pte that isn't mapping a page proper... likely some device driver that I'm not using that is doing something, expected fix is on the one liner size to the khugepaged last patch. Nothing worrysome... but I need more debug data to be sure what it is and to do a proper fix.
Thanks a lot!
Andrea
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Reading oops first thing that comes to mind is this, this is good idea anyway but it's untested, no time right now, tomorrow continue...
mm/huge_memory.c +16 -7
@@ -1310,12 +1310,15 @@ static void release_all_pte_pages(pte_trelease_pte_pages (pte, pte +HPAGE_PMD_NR ); } -static int __collapse_huge_page_isolate (pte_t *pte) +static int __collapse_huge_page_isolate (struct vm_area_struct *vma, +unsigned long address, +pte_t *pte) {struct page *page;pte_t *_pte;int referenced =0 , isolated =0 ; -for (_pte = pte; _pte < pte+HPAGE_PMD_NR ; _pte++) { +for (_pte = pte; _pte < pte+HPAGE_PMD_NR ; + _pte++, address +=PAGE_SIZE ) {pte_t pteval = *_pte;if (!pte_present (pteval) || !pte_write (pteval)) {release_pte_pages (pte, _pte);
@@ -1324,7 +1327,11 @@ static int __collapse_huge_page_isolate(/* If there is no mapped pte young don't collapse the page */ if (pte_young (pteval)) referenced =1 ; - page =pte_page (pteval); + page =vm_normal_page (vma, address, pteval); +if (unlikely (!page)) { +release_pte_pages (pte, _pte); + goto out; + }VM_BUG_ON (PageCompound (page));BUG_ON (!PageAnon (page));VM_BUG_ON (!PageSwapBacked (page));
@@ -1427,7 +1434,7 @@ static void collapse_huge_page(struct mmif (!(vma->vm_flags &VM_HUGEPAGE ) && !khugepaged_always ()) goto out; -if (!vma->anon_vma || vma->vm_ops) +if (!vma->anon_vma || vma->vm_ops || vma->vm_file) goto out; pgd =pgd_offset (mm, address);
@@ -1455,7 +1462,7 @@ static void collapse_huge_page(struct mmspin_unlock (&mm->page_table_lock);spin_lock (ptl); - isolated =__collapse_huge_page_isolate (pte); + isolated =__collapse_huge_page_isolate (vma, address, pte);spin_unlock (ptl);pte_unmap (pte);
@@ -1540,7 +1547,9 @@ static int khugepaged_scan_pmd(struct mm goto out_unmap;if (pte_young (pteval)) referenced =1 ; - page =pte_page (pteval); + page =vm_normal_page (vma, address, pteval); +if (unlikely (!page)) + goto out_unmap;VM_BUG_ON (PageCompound (page));if (!PageLRU (page) ||PageLocked (page) || !PageAnon (page)) goto out_unmap;
@@ -1619,7 +1628,7 @@ static unsigned int khugepaged_scan_mm_s progress++;continue ; } -if (!vma->anon_vma || vma->vm_ops) { +if (!vma->anon_vma || vma->vm_ops || vma->vm_file) { khugepaged_scan.address = vma->vm_end; progress++;continue ;
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
and this incremental one too or address won't be just right...
mm/huge_memory.c +4 -2
@@ -1526,6 +1524,7 @@pte_t *pte, *_pte;int ret =0 , referenced =0 ;struct page *page; +unsigned long _address;VM_BUG_ON (address & ~HPAGE_PMD_MASK );
@@ -1542,14 +1541,15 @@ goto out; pte =pte_offset_map (pmd, address); -for (_pte = pte; _pte < pte+HPAGE_PMD_NR ; _pte++) { +for (_address = address, _pte = pte; _pte < pte+HPAGE_PMD_NR ; + _pte++, _address +=PAGE_SIZE ) {pte_t pteval = *_pte;barrier ();/* read from memory */ if (!pte_present (pteval) || !pte_write (pteval)) goto out_unmap;if (pte_young (pteval)) referenced =1 ; - page =vm_normal_page (vma, address, pteval); + page =vm_normal_page (vma, _address, pteval);if (unlikely (!page)) goto out_unmap;VM_BUG_ON (PageCompound (page));
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 1 line · Andrea Arcangeli
and this incremental one too or address won't be just right...
Hi Andrea, after applying these two patches, my laptop boots fine now, and I have not seen any more issues.
Thanks!
Signature · 7 lines
MST -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Apparently that wasn't enough to fix the bug, it removed the crash but it still trips on vm_normal_page.
What happens is that khugepaged is scanning pagetables and validating them. So if something's wrong it finds it and bugs out (not sure why munmap doesn't though, but maybe app only quits at reboot time and printk is lost in the noise, dunno).
Anyway the broken invariant is pte_special is set and nor PFNMAP nor MIXEDMAP is set. I tracked the pfn pointing inside the 256M memory of the graphics card, so it's likely drm_vm calling remap_pfn_range that leaves corruption in X pagetables (but again not sure why X doesn't trip on exit). Maybe it calls it with different arguments at different times.
The only suspicious thing I found so far is the below, so it'd help if you could review. khugepaged was wrong before not using vm_normal_page, but I don't think it's my bug anymore, though not guaranteed, which is why I hope somebody can help me if below fix is right or not. I don't know if this makes the error go away, I can't reproduce here on my laptop also with drm. But this is the only place I found that clears PFNMAP so it has to be this one...
---------------------
Subject: fix remap_pfn_range pte corruption
From: Andrea Arcangeli <[email protected]>
This line would leave pte_special ptes instantiated, on a vma without VM_PFNMAP set. khugepaged would then trip on this calling vm_normal_page on such a special pte.
---
mm/memory.c +0 -1
@@ -1792,7 +1792,6 @@ int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,* To indicate that track_pfn related cleanup is not * needed from higher level routine calling unmap_vmas */ - vma->vm_flags &= ~(VM_IO |VM_RESERVED |VM_PFNMAP ); vma->vm_flags &= ~VM_PFN_AT_MMAP ;return -EINVAL ; }
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>