Transparent Hugepage Support #15
Subsystems (29)
PATCH 1/1 Transparent Hugepage Support #15
Hello,
this fixes a potential issue with regard to simultaneous 4k and 2M TLB entries in split_huge_page (at pratically zero cost, so I didn't need to add a fake feature flag and it's a lot safer to do it this way just in case). split_large_page in change_page_attr has the same issue too, but I've no idea how to fix it there because the pmd cannot be marked non present at any given time as change_page_attr may be running on ram below 640k and that is the same pmd where the kernel .text resides. However I doubt it'll ever be a practical problem. Other cpus also has a lot of warnings and risks in allowing simultaneous TLB entries of different size.
Johannes also sent a cute optimization to split split_huge_page_vma/mm he converted those in a single split_huge_page_pmd and in addition he also sent native support for hugepages in both mincore and mprotect. Which shows how deep he already understands the whole huge_memory.c and its usage in the callers. Seeing significant contributions like this I think further confirms this is the way to go. Thanks a lot Johannes.
The ability to bisect before the mincore and mprotect native implementations is one of the huge benefits of this approach. The hardest of all will be to add swap native support to 2M pages later (as it involves to make the swapcache 2M capable and that in turn means it expodes more than the rest all over the pagecache code) but I think first we've other priorities:
1) merge memory compaction
2) writing a HPAGE_PMD_ORDER front slab allocator. I don't think memory compaction is capable of relocating slab entries in-use (correct me if I'm wrong, I think it's impossible as long as the slab entries are mapped by 2M pages and not 4k ptes like vmalloc). So the idea is that we should have the slab allocate 2M if it fails, 1M if it fails 512k etc... until it fallbacks to 4k. Otherwise the slab will fragment the memory badly by allocating with alloc_page(). Basically the buddy allocator will guarantee the slab will generate as much fragement as possible because it does its best to keep the high order pages for who asks for them. Probably the fallback should happen inside the buddy allocator instead of calling alloc_pages repeteadly, that should avoid taking a flood of locks. Basically the buddy should give the worst possible fragmentation effect to users that should be relocated, while the other users that cannot be relocated and only use 4k pages will better use a front allocator on top of alloc_pages. Something like alloc_page_not_relocatable() that will do its stuff internally and try to keep those in the same 2M pages. This alone should help tremendously and I think it's orthogonal to the memory compaction of the relocatable stuff. Or maybe we should just live with a large chunk of the memory not being relocatable, but I like this idea because it's more dynamic and it won't have fixed rule "limit the slab to 0-1g range". And it'd tend to try to keep fragmentation down even if we spill over the 1G range. (1g is purely made up number)
3) teach ksm to merge hugepages. I talked about this with Izik and we agree the current ksm tree algorithm will be the best at that compared to ksm algorithms.
To run KVM on top on this and take advantage of hugepages you need a few liner patch I posted to qemu-devel to take care of aligning the start of the guest memory so that the guest physical address and host virtual address will have the same subpage numbers.
http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.6/2.6.34-rc2-mm1/transparent_hugepage-15 http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.6/2.6.34-rc2-mm1/transparent_hugepage-15.gz
I'd be nice to have this merged in -mm.
Thanks,
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>
PATCH 1/1 no paravirt version of pmd ops
From: 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>
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 +15 -0
@@ -13,6 +13,7 @@#include <linux/debug_locks.h> #include <linux/mm_types.h> #include <linux/range.h> +#include <linux/bit_spinlock.h> struct mempolicy ;struct anon_vma ;
@@ -297,6 +298,20 @@ static inline int is_vmalloc_or_module_a }#endif +static 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) {if (unlikely (PageTail (page)))
include/linux/page-flags.h +11 -1
@@ -108,6 +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 */
@@ -399,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.
@@ -408,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 | \ + __PG_COMPOUND_LOCK)/* * Flags checked when a page is prepped for return by the page allocator.
--
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.
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.
Disableing irq before __get_user_page_fast and releasing irq after running compound_head is needed because if __get_user_page_fast 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.
---
kernel/futex.c +58 -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,53 @@ again:if (err <0 )return err; - page =compound_head (page); -lock_page (page); -if (!page->mapping) { -unlock_page (page); +#ifdef CONFIG_TRANSPARENT_HUGEPAGE + 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); +/* +* page_head is valid pointer but we must pin +* it before taking the PG_lock and/or +* PG_compound_lock. The moment we re-enable +* irqs __split_huge_page_splitting() can +* return and the head page can be freed from +* under us. We can't take the PG_lock and/or +* PG_compound_lock on a page that could be +* freed from under us. +*/ +if (page != page_head) +get_page (page_head); +local_irq_enable (); + }else { +local_irq_enable (); + goto again; + } + } +#else + page_head =compound_head (page); +if (page != page_head) +get_page (page_head); +#endif + +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_head); +put_page (page); + goto again; + } + } +if (!page_head->mapping) { +unlock_page (page_head); +if (page_head != page) +put_page (page_head);put_page (page); goto again; }
@@ -265,19 +308,25 @@ 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); +unlock_page (page_head); +if (page != page_head) { +VM_BUG_ON (!PageTail (page)); +/* releasing compound_lock after page_lock won't matter */ +compound_unlock (page_head); +put_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>
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
@@ -470,6 +470,15 @@ static int host_mapping_level(struct kvm page_size =kvm_host_page_size (kvm, gfn); +/* check for transparent hugepages */ +if (page_size ==PAGE_SIZE ) { +struct page *page =gfn_to_page (kvm, gfn); + +if (!is_error_page (page) &&PageTransCompound (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>
PATCH 1/1 don't leave orhpaned swap cache after ksm merging
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
When swapcache is replaced by a ksm page don't leave orhpaned swap cache.
---
mm/ksm.c +1 -1
@@ -817,7 +817,7 @@ static int replace_page(struct vm_area_sset_pte_at_notify (mm, addr, ptep,mk_pte (kpage, vma->vm_page_prot));page_remove_rmap (page); -put_page (page); +free_page_and_swap_cache (page);pte_unmap_unlock (ptep, ptl); err =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 35 of 41] don't leave orhpaned swap cache after ksm merging
Quoted 3 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
When swapcache is replaced by a ksm page don't leave orhpaned swap cache.
Why is this part of the hugepage series?
Quoted 1 line
Signed-off-by Andrea Arcangeli<[email protected]>
--
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 35 of 41] don't leave orhpaned swap cache after ksm merging
Quoted 6 lines · Rik van Riel
Quoted 3 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
When swapcache is replaced by a ksm page don't leave orhpaned swap cache.
Why is this part of the hugepage series?
This is a not relevant for hugepages. There's another ksm change so I thought I could sneak it in. It's still separated so it can be pulled off separately as needed.
--
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 35 of 41] don't leave orhpaned swap cache after ksm merging
Quoted 11 lines · Andrea Arcangeli
Quoted 6 lines · Rik van Riel
Quoted 3 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
When swapcache is replaced by a ksm page don't leave orhpaned swap cache.
Why is this part of the hugepage series?
This is a not relevant for hugepages. There's another ksm change so I thought I could sneak it in. It's still separated so it can be pulled off separately as needed.
It's a nice little catch, but you certainly shouldn't have buried it amidst 40 other patches unrelated to it!
I was going to ack that patch and urge you to forward it to Andrew separately, but did you test whether it works? Isn't it actually a no-op? Because KSM is holding page lock across replace_page() (maybe that's something I added after you were last there - at the time I did it just from instinct, and to make a block look prettier; but later I believe it turned out to be necessary), and free_swap_cache() only works if trylock_page() succeeds.
So if we want the fix, I think it would have to be reworked, perhaps slightly messier.
Something needed for -stable? No, I think not, it's a situation that gradually increases memory pressure, and then memory pressure frees it (vmscan.c's __delete_from_swap_cache); it never prevents swapoff.
But it would be nice to fix it all the same: thanks for spotting.
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 35 of 41] don't leave orhpaned swap cache after ksm merging
Quoted 2 lines · Hugh Dickins
It's a nice little catch, but you certainly shouldn't have buried it amidst 40 other patches unrelated to it!
Yep ;).
Quoted 10 lines
I was going to ack that patch and urge you to forward it to Andrew separately, but did you test whether it works? Isn't it actually a no-op? Because KSM is holding page lock across
replace_page()(maybe that's something I added after you were last there - at the time I did it just from instinct, and to make a block look prettier; but later I believe it turned out to be necessary), andfree_swap_cache()only works iftrylock_page()succeeds.So if we want the fix, I think it would have to be reworked, perhaps slightly messier.
An equivalent patch (a lot messier like you said) was tested and verified for the pre-swap release). Earlier kernels would do nothing in free_page_and_swap_cache unless it was the last reference (they checked page_count(page) != 2, instead of page_mapped()). This is why it was messier in the earlier version for earlier kernel. But I thought doing this there would work and it would be cleaner too by taking advantage of the mapcount check in free_page_and_swap_cache internals.
In the earlier version I'm not doing it inside replace_page so the page lock wouldn't be a problem anyway, but the older version that I'm more familiar with, only takes the PG_lock during page_wrprotect! Why do you keep the PG_lock during replace_page too? do_wp_page can't run as we re-verify the pte didn't change. Maybe is just to be safer?
Quoted 1 line
Something needed for -stable? No, I think not, it's a situation that
Not needed, it's just for statistics and to speedup ksm so that it won't require to invoke the page reclaim to collect orhpaned swapcache that has to go away immediately.
Quoted 4 lines
gradually increases memory pressure, and then memory pressure frees it (vmscan.c's
__delete_from_swap_cache); it never prevents swapoff.But it would be nice to fix it all the same: thanks for spotting.
It wasn't me spotting it, I only fixed it for the earlier version and ported to mainline after verifying the fix works.
Thanks to you for noticing that replace_page now runs under page lock ;).
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>
Re: [PATCH 35 of 41] don't leave orhpaned swap cache after ksm merging
Quoted 3 lines · Andrea Arcangeli
more familiar with, only takes the
PG_lockduringpage_wrprotect! Why do you keep thePG_lockduringreplace_pagetoo?do_wp_pagecan't run as we re-verify the pte didn't change. Maybe is just to be safer?
I re-read it and I can't see any valid reason to hold the PG_lock after write_protect_page returns. The only reason we added the PG_lock is needed is to abort the page merging if there's any GUP pin on the page. And so we must prevent the swapcache to alter the page_count while we read PageSwapCache and we include it in the page_count comparison. We also must read the pte value inside that critical section to re-check it later inside replace_page with pte_same with the PT lock hold to serialize against the VM.
So I think returning to the previous locking should be the preferred way. What do you think? I don't think the fact kpage can be swapped can affect it, "page" should always be a regular anon page and never a ksm page. Otherwise it would be futile to try to wrprotect it in the first place for example.
Let me know if you think something like this could be ok, and I'll send it to Andrew separately (not more mixed with the rest).
Thanks again for spotting it ;).
Andrea
Subject: don't leave orhpaned swap cache after ksm merging
From: Andrea Arcangeli <[email protected]>
When swapcache is replaced by a ksm page don't leave orhpaned swap cache.
---
mm/ksm.c +16 -7
@@ -817,7 +817,7 @@ static int replace_page(struct vm_area_sset_pte_at_notify (mm, addr, ptep,mk_pte (kpage, vma->vm_page_prot));page_remove_rmap (page); -put_page (page); +free_page_and_swap_cache (page);pte_unmap_unlock (ptep, ptl); err =0 ;
@@ -863,7 +863,18 @@ static int try_to_merge_one_page(struct* ptes are necessarily already write-protected. But in either * case, we need to lock and check page_count is not raised. */ -if (write_protect_page (vma, page, &orig_pte) ==0 ) { + err =write_protect_page (vma, page, &orig_pte); + +/* +* After this mapping is wrprotected we don't need further +* checks for PageSwapCache vs page_count unlock_page(page) +* and we rely only on the pte_same() check run under PT lock +* to ensure the pte didn't change since when we wrprotected +* it under PG_lock. +*/ +unlock_page (page); + +if (!err) {if (!kpage) {/* * While we hold page lock, upgrade page from
@@ -872,22 +883,20 @@ static int try_to_merge_one_page(struct*/ set_page_stable_node (page,NULL );mark_page_accessed (page); - err =0 ; }else if (pages_identical (page, kpage)) err =replace_page (vma, page, kpage, orig_pte); - } + }else + err = -EFAULT ;if ((vma->vm_flags &VM_LOCKED ) && kpage && !err) {munlock_vma_page (page);if (!PageMlocked (kpage)) { -unlock_page (page);lock_page (kpage);mlock_vma_page (kpage); - page = kpage;/* for final unlock */ +unlock_page (kpage); } } -unlock_page (page); out:return err; }
--
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 35 of 41] don't leave orhpaned swap cache after ksm merging
Quoted 14 lines · Andrea Arcangeli
Quoted 3 lines · Andrea Arcangeli
more familiar with, only takes the
PG_lockduringpage_wrprotect! Why do you keep thePG_lockduringreplace_pagetoo?do_wp_pagecan't run as we re-verify the pte didn't change. Maybe is just to be safer?I re-read it and I can't see any valid reason to hold the
PG_lockafterwrite_protect_pagereturns. The only reason we added thePG_lockis needed is to abort the page merging if there's any GUP pin on the page. And so we must prevent the swapcache to alter thepage_countwhile we read PageSwapCache and we include it in thepage_countcomparison. We also must read the pte value inside that critical section to re-check it later insidereplace_pagewithpte_samewith the PT lock hold to serialize against the VM.
Quoted 8 lines
So I think returning to the previous locking should be the preferred way. What do you think? I don't think the fact kpage can be swapped can affect it, "page" should always be a regular anon page and never a ksm page. Otherwise it would be futile to try to wrprotect it in the first place for example.
Let me know if you think something like this could be ok, and I'll send it to Andrew separately (not more mixed with the rest).
I deeply resent you forcing me to think like this ;)
There is a simple bug with your patch below, isn't there? The BUG_ON(!PageLocked(page)) in munlock_vma_page(). I expect that could be worked around with more messiness.
But really you're interested in whether I see an absolute reason why we have to hold page lock across the replace_page(). And no, I can't at this moment name an absolute reason, but still feel as I did when I made that change: it makes thinking about the transition easier.
I just have a feeling that if I thought longer and harder I'd find a good reason for it... but admit that's one of the sloppiest and most dishonest arguments you'll ever meet!
But now I look at this again, I think we can keep that page lock, without being messy at all: we're placing too much faith in "free_page_and_swap_cache" as a primitive construct, when actually its just a collection of things to do.
So why don't you leave try_to_merge_one_page() just as it is, and leave replace_page()'s put_page() as it is, but add in
if (!page_mapped(page)) try_to_free_swap(page);
either before or after the put_page? The page_mapped test is not vital; but if the page is still mapped elsewhere, we usually take that as justification for keeping its swap.
(I should note in passing that really the thing to do here is not necessarily to free the swap, but to consider transferring the swap to the KSM page. If all goes well, the KSM page remains stable and we should be able to reread it from swap later on, without having to write it out there again. But the way swapping of KSM pages works, the chance that the KSM page will be the one that's already PageSwapcache is fairly low; and so we do repeatedly write them out to swap. I was working to avoid that when doing the KSM swapping, but it grew such a long conditional expression - almost as long as the Cc list on this mail - and became so awkward between replace_page and try_to_merge_one_page, that I decided to put it all off to a later optimization. That I've never yet got around to.)
Hugh
Quoted 61 lines
Thanks again for spotting it ;).
AndreaSubject: don't leave orhpaned swap cache after ksm merging
From: Andrea Arcangeli <[email protected]>
When swapcache is replaced by a ksm page don't leave orhpaned swap cache.
Signed-off-by Andrea Arcangeli <[email protected]>---
mm/ksm.c +15
-5@@ -817,7 +817,7 @@ static int replace_page(struct vm_area_sset_pte_at_notify (mm, addr, ptep,mk_pte (kpage, vma->vm_page_prot));page_remove_rmap (page); -put_page (page); +free_page_and_swap_cache (page);pte_unmap_unlock (ptep, ptl); err =0 ;@@ -863,7 +863,18 @@ static int try_to_merge_one_page(struct* ptes are necessarily already write-protected. But in either * case, we need to lock and check page_count is not raised. */ -if (write_protect_page (vma, page, &orig_pte) ==0 ) { + err =write_protect_page (vma, page, &orig_pte); + +/* +* After this mapping is wrprotected we don't need further +* checks for PageSwapCache vs page_count unlock_page(page) +* and we rely only on the pte_same() check run under PT lock +* to ensure the pte didn't change since when we wrprotected +* it under PG_lock. +*/ +unlock_page (page); + +if (!err) {if (!kpage) {/* * While we hold page lock, upgrade page from @@ -872,22 +883,20 @@ static int try_to_merge_one_page(struct*/ set_page_stable_node (page,NULL );mark_page_accessed (page); - err =0 ; }else if (pages_identical (page, kpage)) err =replace_page (vma, page, kpage, orig_pte); - } + }else + err = -EFAULT ;if ((vma->vm_flags &VM_LOCKED ) && kpage && !err) {munlock_vma_page (page);if (!PageMlocked (kpage)) { -unlock_page (page);lock_page (kpage);
mm/ksm.c static int try_to_merge_one_page(struct · line 902
Quoted 10 lines
mm/ksm.c +1
-2mlock_vma_page (kpage); - page = kpage;/* for final unlock */ +unlock_page (kpage); } } -unlock_page (page); out:return err; }
--
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 35 of 41] don't leave orhpaned swap cache after ksm merging
Quoted 1 line · Hugh Dickins
I deeply resent you forcing me to think like this ;)
sorry ;)
Quoted 3 lines
There is a simple bug with your patch below, isn't there? The BUG_ON(!PageLocked(page)) in
munlock_vma_page(). I expect that could be worked around with more messiness.
Didn't notice this, no more messiness just like in do_wp_page:
lock_page(old_page); /* for LRU manipulation */
clear_page_mlock(old_page);
unlock_page(old_page);mm/ksm.c +2 -0
@@ -889,7 +889,9 @@ static int try_to_merge_one_page(struct err = -EFAULT ;if ((vma->vm_flags &VM_LOCKED ) && kpage && !err) { +lock_page (page);/* for LRU manipulation */ munlock_vma_page (page); +unlock_page (page);if (!PageMlocked (kpage)) {lock_page (kpage);mlock_vma_page (kpage);
So no big deal, the chances we block in that lock are close to zero considering we just released it. The VM could still take it because the page is still in the lru, but it will bail out when it sees the page_mapcount() == 0. So no risk to wait for I/O.
Quoted 4 lines
But really you're interested in whether I see an absolute reason why we have to hold page lock across the
replace_page(). And no, I can't at this moment name an absolute reason, but still feel as I did when I made that change: it makes thinking about the transition easier.
What about do_wp_page? It also reads the orig_pte. It takes the page lock just to run reuse_swap_cache. If that fails it drops the PT lock allocates the page, take the PT lock again, runs pte_same the same way reuse_swap_cache does it, and finally it copies and replaces the page.
How is that any different? I mean are we introducing a new case or it's the same as do_wp_page.
I think it boils down to the answer of the above question. I think they're equal, but if you think they're different I'll keep the lock hold during replace_page no problem. I don't want to introduce new locking cases, but to me it doesn't look like one!
Quoted 7 lines
So why don't you leave
try_to_merge_one_page()just as it is, and leave replace_page()'sput_page()as it is, but add inif (!page_mapped(page)) try_to_free_swap(page);either before or after the
put_page? Thepage_mappedtest is not vital; but if the page is still mapped elsewhere, we usually take that as justification for keeping its swap.
No doubt we can leave the page lock around replace_page too, but I personally hate to leave unknown-needed locking, especially if there are other places that release the page lock and they only relies on the pte_same check under PT lock when they replace the page (do_wp_page).
Originally, before I found the trouble with the gup pins in page_wrprotect (current write_protect_page) we didn't take the PG_lock at all. We had to introduce it to do the page_count accounting right on the swapcache and that's about it...
Quoted 5 lines
(I should note in passing that really the thing to do here is not necessarily to free the swap, but to consider transferring the swap to the KSM page. If all goes well, the KSM page remains stable and we should be able to reread it from swap later on, without having to write it out there again. But the way swapping
Agreed that would be ideal. It'd save one I/O if both pte and swapcache are clean, and it might improve swap locality even when one of the two is dirty.
Quoted 7 lines
of KSM pages works, the chance that the KSM page will be the one that's already PageSwapcache is fairly low; and so we do repeatedly write them out to swap. I was working to avoid that when doing the KSM swapping, but it grew such a long conditional expression - almost as long as the Cc list on this mail - and became so awkward between
replace_pageandtry_to_merge_one_page, that I decided to put it all off to a later optimization. That I've never yet got around to.)
No problem. It's not high priority for sure. The only high priority thing as far as KSM is concerned is to make it work on hugepages. For now shutting down a VM and not being life with gigabytes of swap used is enough...
--
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 don't alloc harder for gfp nomemalloc even if nowait
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Not worth throwing away the precious reserved free memory pool for allocations that can fail gracefully (either through mempool or because they're transhuge allocations later falling back to 4k allocations).
---
mm/page_alloc.c +5 -1
@@ -1811,7 +1811,11 @@ gfp_to_alloc_flags(gfp_t gfp_mask)*/ alloc_flags |= (gfp_mask & __GFP_HIGH); -if (!wait) { +/* +* Not worth trying to allocate harder for __GFP_NOMEMALLOC +* even if it can't schedule. +*/ +if (!wait && !(gfp_mask & __GFP_NOMEMALLOC)) { alloc_flags |=ALLOC_HARDER ;/* * Ignore cpuset if GFP_ATOMIC (!wait) rather than fail alloc.
--
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.
In theory we could split pages before isolating them during the lru scan, 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.
---
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
@@ -1284,6 +1284,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
@@ -937,6 +937,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>
PATCH 1/1 skip transhuge pages in ksm for now
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Skip transhuge pages in ksm for now.
---
mm/ksm.c +14 -3
@@ -1294,7 +1294,19 @@ next_mm:if (ksm_test_exit (mm))break ; *page =follow_page (vma, ksm_scan.address,FOLL_GET ); -if (*page &&PageAnon (*page)) { +if (!*page) { + ksm_scan.address +=PAGE_SIZE ; +cond_resched (); +continue ; + } +if (PageTransHuge (*page)) { +put_page (*page); + ksm_scan.address &=HPAGE_PMD_MASK ; + ksm_scan.address +=HPAGE_PMD_SIZE ; +cond_resched (); +continue ; + } +if (PageAnon (*page)) {flush_anon_page (vma, *page, ksm_scan.address);flush_dcache_page (*page); rmap_item = get_next_rmap_item(slot,
@@ -1308,8 +1320,7 @@ next_mm:up_read (&mm->mmap_sem);return rmap_item; } -if (*page) -put_page (*page); +put_page (*page); ksm_scan.address +=PAGE_SIZE ;cond_resched (); }
--
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 36 of 41] skip transhuge pages in ksm for now
Quoted 5 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Skip transhuge pages in ksm for now.
Signed-off-by Andrea Arcangeli<[email protected]>
--
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
@@ -5291,7 +5291,7 @@ void dump_page(struct page *page) {printk (KERN_ALERT "page:%p count:%d mapcount:%d mapping:%p index:%#lx\n" , - page,page_count (page),page_mapcount (page), + page,atomic_read (&page->_count),page_mapcount (page), page->mapping, page->index);dump_page_flags (page->flags); }
--
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
@@ -724,6 +724,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
@@ -795,8 +795,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 ;
@@ -824,7 +829,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 );
@@ -871,7 +879,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
@@ -657,6 +657,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 33 of 41] transparent hugepage vmstat
Quoted 4 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
Add hugepage stat information to
/proc/vmstatand/proc/meminfo.
I'm sorry if it has been discussed already, but shouldn't we also count LRU_(IN)ACTIVE_LRU properly ? Is it a TODO ?
Thanks,
Daisuke Nishimura.
Quoted 111 lines
Signed-off-by Andrea Arcangeli <[email protected]>Acked-by Rik van Riel <[email protected]>---
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@@ -724,6 +724,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@@ -795,8 +795,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 ;@@ -824,7 +829,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 );@@ -871,7 +879,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
-1@@ -657,6 +657,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", --
Quoted 4 lines
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>
--
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 33 of 41] transparent hugepage vmstat
Quoted 7 lines · Daisuke Nishimura
Quoted 4 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
Add hugepage stat information to
/proc/vmstatand/proc/meminfo.I'm sorry if it has been discussed already, but shouldn't we also count LRU_(IN)ACTIVE_LRU properly ? Is it a TODO ?
Maybe we should it's not huge priority at the moment, it still tells accurately the number of entries in the list, it's not like garbled information but it doesn't reflect strict memory size anymore. It reflects the size of the list instead (only with transparent hugepage support enabled otherwise the exact old behavior is retained). I'm unsure how big issue is that.
--
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 33 of 41] transparent hugepage vmstat
Quoted 9 lines · Andrea Arcangeli
Quoted 7 lines · Daisuke Nishimura
Quoted 4 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
Add hugepage stat information to
/proc/vmstatand/proc/meminfo.I'm sorry if it has been discussed already, but shouldn't we also count LRU_(IN)ACTIVE_LRU properly ? Is it a TODO ?
typo of LRU_(IN)ACTIVE_ANON of course ;)
Quoted 6 lines
Maybe we should it's not huge priority at the moment, it still tells accurately the number of entries in the list, it's not like garbled information but it doesn't reflect strict memory size anymore. It reflects the size of the list instead (only with transparent hugepage support enabled otherwise the exact old behavior is retained). I'm unsure how big issue is that.
Hmm, "the size of the lists" might be enough for vmscan calculation, (but, sorry, I'm not a vmscan expert).
But "Active/Inactive(anon)" in /proc/meminfo would become inaccurate. Yes, it might not be a big deal(it doesn't cause panic), but I think we should let users know about it by a documentation or something.
Thanks,
Daisuke Nishimura.
--
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
In reply to Andrea ArcangeliFrom: 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>
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
@@ -629,6 +629,8 @@ static void __free_pages_ok(struct pagetrace_mm_page_free_direct (page, order);kmemcheck_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>
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
@@ -440,6 +440,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)
@@ -447,6 +452,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;
@@ -548,6 +559,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>
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 +125 -0
@@ -25,6 +25,26 @@ })#endif +#ifndef __HAVE_ARCH_PMDP_SET_ACCESS_FLAGS +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +#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; \ + }) +#else /* CONFIG_TRANSPARENT_HUGEPAGE */ +#define pmdp_set_access_flags (__vma, __address, __pmdp, __entry, __dirty) \ + ({ BUG(); 0; }) +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ +#endif +#ifndef __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG#define ptep_test_and_clear_young (__vma, __address, __ptep) \ ({ \
@@ -39,6 +59,25 @@ })#endif +#ifndef __HAVE_ARCH_PMDP_TEST_AND_CLEAR_YOUNG +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +#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; \ +}) +#else /* CONFIG_TRANSPARENT_HUGEPAGE */ +#define pmdp_test_and_clear_young (__vma, __address, __pmdp) \ + ({ BUG(); 0; }) +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ +#endif +#ifndef __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH#define ptep_clear_flush_young (__vma, __address, __ptep) \ ({ \
@@ -50,6 +89,24 @@ })#endif +#ifndef __HAVE_ARCH_PMDP_CLEAR_YOUNG_FLUSH +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +#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; \ +}) +#else /* CONFIG_TRANSPARENT_HUGEPAGE */ +#define pmdp_clear_flush_young (__vma, __address, __pmdp) \ + ({ BUG(); 0; }) +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ +#endif +#ifndef __HAVE_ARCH_PTEP_GET_AND_CLEAR#define ptep_get_and_clear (__mm, __address, __ptep) \ ({ \
@@ -59,6 +116,20 @@ })#endif +#ifndef __HAVE_ARCH_PMDP_GET_AND_CLEAR +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +#define pmdp_get_and_clear (__mm, __address, __pmdp) \ +({ \ + pmd_t __pmd = *(__pmdp); \ + pmd_clear((__mm), (__address), (__pmdp)); \ + __pmd; \ +}) +#else /* CONFIG_TRANSPARENT_HUGEPAGE */ +#define pmdp_get_and_clear (__mm, __address, __pmdp) \ + ({ BUG(); 0; }) +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ +#endif +#ifndef __HAVE_ARCH_PTEP_GET_AND_CLEAR_FULL#define ptep_get_and_clear_full (__mm, __address, __ptep, __full) \ ({ \
@@ -90,6 +161,22 @@ do { \ })#endif +#ifndef __HAVE_ARCH_PMDP_CLEAR_FLUSH +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +#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; \ +}) +#else /* CONFIG_TRANSPARENT_HUGEPAGE */ +#define pmdp_clear_flush (__vma, __address, __pmdp) \ + ({ BUG(); 0; }) +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ +#endif +#ifndef __HAVE_ARCH_PTEP_SET_WRPROTECTstruct mm_struct ;static inline void ptep_set_wrprotect (struct mm_struct *mm,unsigned long address,pte_t *ptep)
@@ -99,10 +186,45 @@ static inline void ptep_set_wrprotect(st }#endif +#ifndef __HAVE_ARCH_PMDP_SET_WRPROTECT +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +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)); +} +#else /* CONFIG_TRANSPARENT_HUGEPAGE */ +#define pmdp_set_wrprotect (mm, address, pmdp) BUG() +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ +#endif + +#ifndef __HAVE_ARCH_PMDP_SPLITTING_FLUSH +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +#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 );\ +}) +#else /* CONFIG_TRANSPARENT_HUGEPAGE */ +#define pmdp_splitting_flush (__vma, __address, __pmdp) BUG() +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ +#endif +#ifndef __HAVE_ARCH_PTE_SAME#define pte_same (A ,B ) (pte_val(A) == pte_val(B))#endif +#ifndef __HAVE_ARCH_PMD_SAME +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +#define pmd_same (A ,B ) (pmd_val(A) == pmd_val(B)) +#else /* CONFIG_TRANSPARENT_HUGEPAGE */ +#define pmd_same (A ,B ) ({ BUG(); 0; }) +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ +#endif +#ifndef __HAVE_ARCH_PAGE_TEST_DIRTY#define page_test_dirty (page) (0)#endif
@@ -347,6 +469,9 @@ extern void untrack_pfn_vma(struct vm_ar#ifndef CONFIG_TRANSPARENT_HUGEPAGE #define pmd_trans_huge (pmd) 0#define pmd_trans_splitting (pmd) 0 +#ifndef __HAVE_ARCH_PMD_WRITE +#define pmd_write (pmd) ({ BUG(); 0; }) +#endif /* __HAVE_ARCH_PMD_WRITE */ #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>
PATCH 1/1 _GFP_NO_KSWAPD
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Transparent hugepage allocations must be allowed not to invoke kswapd or any other kind of indirect reclaim (especially when the defrag sysfs is control disabled). It's unacceptable to swap out anonymous pages (potentially anonymous transparent hugepages) in order to create new transparent hugepages. This is true for the MADV_HUGEPAGE areas too (swapping out a kvm virtual machine and so having it suffer an unbearable slowdown, so another one with guest physical memory marked MADV_HUGEPAGE can run 30% faster if it is running memory intensive workloads, makes no sense). If a transparent hugepage allocation fails the slowdown is minor and there is total fallback, so kswapd should never be asked to swapout memory to allow the high order allocation to succeed.
---
include/linux/gfp.h +3 -1
@@ -60,13 +60,15 @@ struct vm_area_struct;#define __GFP_NOTRACK ((__force gfp_t)0)#endif +#define __GFP_NO_KSWAPD ((__force gfp_t)0x400000u) +/* * This may seem redundant, but it's a way of annotating false positives vs. * allocations that simply cannot be supported (e.g. page tables). */ #define __GFP_NOTRACK_FALSE_POSITIVE (__GFP_NOTRACK) -#define __GFP_BITS_SHIFT 22/* Room for 22 __GFP_FOO bits */ +#define __GFP_BITS_SHIFT 23/* Room for 23 __GFP_FOO bits */ #define __GFP_BITS_MASK ((__force gfp_t)((1 << __GFP_BITS_SHIFT) - 1))/* This equals 0, but use constants in case they ever change */
mm/page_alloc.c +2 -1
@@ -1867,7 +1867,8 @@ __alloc_pages_slowpath(gfp_t gfp_mask, u goto nopage; restart: -wake_all_kswapd (order, zonelist, high_zoneidx); +if (!(gfp_mask & __GFP_NO_KSWAPD)) +wake_all_kswapd (order, zonelist, high_zoneidx);/* * OK, we're below the kswapd watermark and have kicked background
--
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
@@ -334,6 +334,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>
PATCH 1/1 split_huge_page_mm/vma
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
split_huge_page_pmd 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_pmd design.
---
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_pmd (mm, pmd);if (pmd_none_or_clear_bad (pmd)) goto out; pte =pte_offset_map_lock (mm, pmd,0xA0000 , &ptl);
mm/mempolicy.c +1 -0
@@ -443,6 +443,7 @@ static inline int check_pmd_range(struct pmd =pmd_offset (pud, addr); do { next = pmd_addr_end(addr, end); + split_huge_page_pmd(vma->vm_mm, pmd); if (pmd_none_or_clear_bad(pmd)) continue; if (check_pte_range(vma, pmd, addr, next, nodes,
mm/mincore.c +1 -0
@@ -154,6 +154,7 @@ static void mincore_pmd_range(struct vm_ pmd =pmd_offset (pud, addr); do { next = pmd_addr_end(addr, end); + split_huge_page_pmd(vma->vm_mm, pmd); if (pmd_none_or_clear_bad(pmd)) mincore_unmapped_range(vma, addr, next, vec); else
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_pmd(mm, 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_pmd (mm, 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_pmd(walk->mm, 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>
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
@@ -160,7 +160,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>
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
@@ -1067,7 +1067,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);/*
@@ -1136,12 +1137,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
@@ -396,9 +396,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 ;
@@ -418,14 +420,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 ; }
@@ -438,10 +444,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);
@@ -3119,7 +3126,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>
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).
_PAGE_BIT_UNUSED1 is never used for pmd, only on pte.
---
arch/x86/include/asm/pgtable_64.h +13 -0
@@ -168,6 +168,19 @@ extern void cleanup_highmap(void);#define kc_offset_to_vaddr (o) ((o) | ~__VIRTUAL_MASK)#define __HAVE_ARCH_PTE_SAME + +#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 */ +#endif /* !__ASSEMBLY__ */ #endif /* _ASM_X86_PGTABLE_64_H */
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 +5 -0
@@ -344,6 +344,11 @@ extern void untrack_pfn_vma(struct vm_ar unsigned long size);#endif +#ifndef CONFIG_TRANSPARENT_HUGEPAGE +#define pmd_trans_huge (pmd) 0 +#define pmd_trans_splitting (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>
PATCH 1/1 config_transparent_hugepage
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Add config option.
---
mm/Kconfig +14 -0
@@ -287,3 +287,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>
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
@@ -99,6 +99,7 @@ extern void __split_huge_page_pmd(struct#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));
@@ -121,6 +122,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 +16 -0
@@ -840,6 +840,22 @@ 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 ; +} +void __split_huge_page_pmd (struct mm_struct *mm,pmd_t *pmd) {struct page *page;
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>
PATCH 1/1 verify pmd_trans_huge isn't leaking
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
pte_trans_huge must not leak in certain vmas like the mmio special pfn or filebacked mappings.
---
mm/memory.c +6 -1
@@ -1421,6 +1421,7 @@ int __get_user_pages(struct task_struct pmd =pmd_offset (pud, pg);if (pmd_none (*pmd))return i ? : -EFAULT ; +VM_BUG_ON (pmd_trans_huge (*pmd)); pte =pte_offset_map (pmd, pg);if (pte_none (*pte)) {pte_unmap (pte);
@@ -1622,8 +1623,10 @@ pte_t *get_locked_pte(struct mm_struct *pud_t * pud =pud_alloc (mm, pgd, addr);if (pud) {pmd_t * pmd =pmd_alloc (mm, pud, addr); -if (pmd) +if (pmd) { +VM_BUG_ON (pmd_trans_huge (*pmd));return pte_alloc_map_lock (mm, pmd, addr, ptl); + } }return NULL ; }
@@ -1842,6 +1845,7 @@ static inline int remap_pmd_range(struct pmd =pmd_alloc (mm, pud, addr);if (!pmd)return -ENOMEM ; +VM_BUG_ON (pmd_trans_huge (*pmd)); do { next = pmd_addr_end(addr, end); if (remap_pte_range(mm, pmd, addr, next,
@@ -3317,6 +3321,7 @@ static int follow_pte(struct mm_struct * goto out; pmd =pmd_offset (pud, address); +VM_BUG_ON (pmd_trans_huge (*pmd));if (pmd_none (*pmd) ||unlikely (pmd_bad (*pmd))) goto out;
--
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.
---
arch/alpha/include/asm/mman.h +2 -0
@@ -53,6 +53,8 @@#define MADV_MERGEABLE 12/* KSM may merge identical pages */ #define MADV_UNMERGEABLE 13/* KSM may not merge identical pages */ +#define MADV_HUGEPAGE 14/* Worth backing with hugepages */ +/* compatibility flags */ #define MAP_FILE 0
arch/mips/include/asm/mman.h +2 -0
@@ -77,6 +77,8 @@#define MADV_UNMERGEABLE 13/* KSM may not merge identical pages */ #define MADV_HWPOISON 100/* poison a page for testing */ +#define MADV_HUGEPAGE 14/* Worth backing with hugepages */ +/* compatibility flags */ #define MAP_FILE 0
arch/parisc/include/asm/mman.h +2 -0
@@ -59,6 +59,8 @@#define MADV_MERGEABLE 65/* KSM may merge identical pages */ #define MADV_UNMERGEABLE 66/* KSM may not merge identical pages */ +#define MADV_HUGEPAGE 67/* Worth backing with hugepages */ +/* compatibility flags */ #define MAP_FILE 0#define MAP_VARIABLE 0
arch/xtensa/include/asm/mman.h +2 -0
@@ -83,6 +83,8 @@#define MADV_MERGEABLE 12/* KSM may merge identical pages */ #define MADV_UNMERGEABLE 13/* KSM may not merge identical pages */ +#define MADV_HUGEPAGE 14/* Worth backing with hugepages */ +/* compatibility flags */ #define MAP_FILE 0
include/asm-generic/mman-common.h +1 -1
@@ -45,7 +45,7 @@#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 */ +#define MADV_HUGEPAGE 14/* 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>
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>
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
@@ -390,6 +390,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
@@ -2031,19 +2031,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>
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 +12 -0
@@ -16,6 +16,16 @@#ifdef __HAVE_ARCH_PTE_SPECIAL +static inline void pin_huge_page_tail (struct page *page) +{ +/* +* __split_huge_page_refcount() cannot run +* from under us. +*/ +VM_BUG_ON (atomic_read (&page->_count) <0 ); +atomic_inc (&page->_count); +} +/* * The performance critical leaf functions are made noinline otherwise gcc * inlines everything into a single function which results in too much
@@ -47,6 +57,8 @@ static noinline int gup_pte_range(pmd_tput_page (page);return 0 ; } +if (PageTail (page)) +pin_huge_page_tail (page); pages[*nr] = page; (*nr)++;
arch/x86/mm/gup.c +12 -0
@@ -105,6 +105,16 @@ static inline void get_head_page_multiplatomic_add (nr, &page->_count); } +static inline void pin_huge_page_tail (struct page *page) +{ +/* +* __split_huge_page_refcount() cannot run +* from under us. +*/ +VM_BUG_ON (atomic_read (&page->_count) <0 ); +atomic_inc (&page->_count); +} + static noinline int gup_huge_pmd(pmd_t pmd, unsigned long addr,unsigned long end,int write,struct page **pages,int *nr) {
@@ -128,6 +138,8 @@ static noinline int gup_huge_pmd(pmd_t p do { VM_BUG_ON(compound_head(page) != head); pages[*nr] = page; + if (PageTail(page)) + pin_huge_page_tail(page); (*nr)++; page++; refs++;
include/linux/mm.h +10 -2
@@ -326,9 +326,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)
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>
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) != (1 << PG_compound)); +clear_bit (PG_compound, &page->flags); +} +#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>
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
@@ -1507,5 +1507,14 @@ extern int soft_offline_page(struct pageextern void dump_page (struct page *page); +#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 +3 -66
87 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>
PATCH 1/1 add pmd_modify
In reply to Andrea ArcangeliFrom: Johannes Weiner <[email protected]>
Add pmd_modify() for use with mprotect() on huge pmds.
---
arch/x86/include/asm/pgtable.h +10 -0
@@ -323,6 +323,16 @@ static inline pte_t pte_modify(pte_t ptereturn __pte (val); } +static inline pmd_t pmd_modify (pmd_t pmd,pgprot_t newprot) +{ +pmdval_t val =pmd_val (pmd); + + val &= _HPAGE_CHG_MASK; + val |=massage_pgprot (newprot) & ~_HPAGE_CHG_MASK; + +return __pmd (val); +} +/* mprotect needs to preserve PAT bits when updating vm_page_prot */ #define pgprot_modify pgprot_modifystatic inline pgprot_t pgprot_modify (pgprot_t oldprot,pgprot_t newprot)
arch/x86/include/asm/pgtable_types.h +1 -0
@@ -72,6 +72,7 @@/* Set of bits not changed in pte_modify */ #define _PAGE_CHG_MASK (PTE_PFN_MASK | _PAGE_PCD | _PAGE_PWT | \ _PAGE_SPECIAL | _PAGE_ACCESSED | _PAGE_DIRTY) +#define _HPAGE_CHG_MASK (_PAGE_CHG_MASK | _PAGE_PSE)#define _PAGE_CACHE_MASK (_PAGE_PCD | _PAGE_PWT)#define _PAGE_CACHE_WB (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 39 of 41] add pmd_modify
Quoted 6 lines · Andrea Arcangeli
From: Johannes Weiner<[email protected]>
Add
pmd_modify()for use withmprotect()on huge pmds.Signed-off-by Johannes Weiner<[email protected]>Signed-off-by Andrea Arcangeli<[email protected]>
--
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 mprotect: pass vma down to page table walkers
In reply to Andrea ArcangeliFrom: Johannes Weiner <[email protected]>
Waiting for huge pmds to finish splitting requires the vma's anon_vma, so pass along the vma instead of the mm, we can always get the latter when we need it.
---
mm/mprotect.c +8 -7
@@ -36,10 +36,11 @@ static inline pgprot_t pgprot_modify(pgp }#endif -static void change_pte_range (struct mm_struct *mm,pmd_t *pmd, +static void change_pte_range (struct vm_area_struct *vma,pmd_t *pmd,unsigned long addr,unsigned long end,pgprot_t newprot,int dirty_accountable) { +struct mm_struct *mm = vma->vm_mm;pte_t *pte, oldpte;spinlock_t *ptl;
@@ -79,7 +80,7 @@ static void change_pte_range(struct mm_spte_unmap_unlock (pte -1 , ptl); } -static inline void change_pmd_range (struct mm_struct *mm,pud_t *pud, +static inline void change_pmd_range (struct vm_area_struct *vma,pud_t *pud,unsigned long addr,unsigned long end,pgprot_t newprot,int dirty_accountable) {
@@ -89,14 +90,14 @@ static inline void change_pmd_range(stru pmd =pmd_offset (pud, addr);do { next =pmd_addr_end (addr, end); -split_huge_page_pmd (mm, pmd); +split_huge_page_pmd (vma->vm_mm, pmd);if (pmd_none_or_clear_bad (pmd))continue ; -change_pte_range (mm, pmd, addr, next, newprot, dirty_accountable); +change_pte_range (vma, pmd, addr, next, newprot, dirty_accountable); }while (pmd++, addr = next, addr != end); } -static inline void change_pud_range (struct mm_struct *mm,pgd_t *pgd, +static inline void change_pud_range (struct vm_area_struct *vma,pgd_t *pgd,unsigned long addr,unsigned long end,pgprot_t newprot,int dirty_accountable) {
@@ -108,7 +109,7 @@ static inline void change_pud_range(stru next =pud_addr_end (addr, end);if (pud_none_or_clear_bad (pud))continue ; -change_pmd_range (mm, pud, addr, next, newprot, dirty_accountable); +change_pmd_range (vma, pud, addr, next, newprot, dirty_accountable); }while (pud++, addr = next, addr != end); }
@@ -128,7 +129,7 @@ static void change_protection(struct vm_ next =pgd_addr_end (addr, end);if (pgd_none_or_clear_bad (pgd))continue ; -change_pud_range (mm, pgd, addr, next, newprot, dirty_accountable); +change_pud_range (vma, pgd, addr, next, newprot, dirty_accountable); }while (pgd++, addr = next, addr != end);flush_tlb_range (vma, start, end); }
--
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 40 of 41] mprotect: pass vma down to page table walkers
Quoted 8 lines · Andrea Arcangeli
From: Johannes Weiner<[email protected]>
Waiting for huge pmds to finish splitting requires the vma's
anon_vma, so pass along the vma instead of the mm, we can always get the latter when we need it.Signed-off-by Johannes Weiner<[email protected]>Signed-off-by Andrea Arcangeli<[email protected]>
--
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 mincore transparent hugepage support
In reply to Andrea ArcangeliFrom: Johannes Weiner <[email protected]>
Handle transparent huge page pmd entries natively instead of splitting them into subpages.
---
include/linux/huge_mm.h +3 -0
@@ -19,6 +19,9 @@ extern struct page *follow_trans_huge_pmextern int zap_huge_pmd (struct mmu_gather *tlb,struct vm_area_struct *vma,pmd_t *pmd); +extern int mincore_huge_pmd (struct vm_area_struct *vma,pmd_t *pmd, +unsigned long addr,unsigned long end, +unsigned char *vec);enum transparent_hugepage_flag {TRANSPARENT_HUGEPAGE_FLAG ,
mm/huge_memory.c +25 -0
@@ -936,6 +936,31 @@ int zap_huge_pmd(struct mmu_gather *tlb,return ret; } +int mincore_huge_pmd (struct vm_area_struct *vma,pmd_t *pmd, +unsigned long addr,unsigned long end, +unsigned char *vec) +{ +int ret =0 ; + +spin_lock (&vma->vm_mm->page_table_lock); +if (likely (pmd_trans_huge (*pmd))) { + ret = !pmd_trans_splitting (*pmd); +spin_unlock (&vma->vm_mm->page_table_lock); +if (unlikely (!ret)) +wait_split_huge_page (vma->anon_vma, pmd); +else { +/* +* All logical pages in the range are present +* if backed by a huge page. +*/ +memset (vec,1 , (end - addr) >>PAGE_SHIFT ); + } + }else +spin_unlock (&vma->vm_mm->page_table_lock); + +return ret; +} + pmd_t *page_check_address_pmd(struct page *page, struct mm_struct *mm, unsigned long address,
mm/mincore.c +7 -1
@@ -154,7 +154,13 @@ static void mincore_pmd_range(struct vm_ pmd =pmd_offset (pud, addr); do { next = pmd_addr_end(addr, end); - split_huge_page_pmd(vma->vm_mm, pmd); + if (pmd_trans_huge(*pmd)) { + if (mincore_huge_pmd(vma, pmd, addr, next, vec)) { + vec += (next - addr) >> PAGE_SHIFT; + continue; + } + /* fall through */ + } if (pmd_none_or_clear_bad(pmd)) mincore_unmapped_range(vma, addr, next, vec); else
--
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 38 of 41] mincore transparent hugepage support
Quoted 7 lines · Andrea Arcangeli
From: Johannes Weiner<[email protected]>
Handle transparent huge page pmd entries natively instead of splitting them into subpages.
Signed-off-by Johannes Weiner<[email protected]>Signed-off-by Andrea Arcangeli<[email protected]>
--
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 x86 32bit support
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Add support for transparent hugepages to x86 32bit.
Share the same VM_ bitflag for VM_MAPPED_COPY. mm/nommu.c will never support transparent hugepages.
---
arch/x86/include/asm/pgtable-2level.h +9 -0
@@ -46,6 +46,15 @@ static inline pte_t native_ptep_get_and_#define native_ptep_get_and_clear (xp) native_local_ptep_get_and_clear(xp)#endif +#ifdef CONFIG_SMP +static inline pmd_t native_pmdp_get_and_clear (pmd_t *xp) +{ +return __pmd (xchg ((pmdval_t *)xp,0 )); +} +#else +#define native_pmdp_get_and_clear (xp) native_local_pmdp_get_and_clear(xp) +#endif +/* * Bits _PAGE_BIT_PRESENT, _PAGE_BIT_FILE and _PAGE_BIT_PROTNONE are taken, * split up the 29 bits of offset into this range:
arch/x86/include/asm/pgtable-3level.h +23 -0
@@ -104,6 +104,29 @@ static inline pte_t native_ptep_get_and_#define native_ptep_get_and_clear (xp) native_local_ptep_get_and_clear(xp)#endif +#ifdef CONFIG_SMP +union split_pmd { +struct { +u32 pmd_low; +u32 pmd_high; + }; +pmd_t pmd; +}; +static inline pmd_t native_pmdp_get_and_clear (pmd_t *pmdp) +{ +union split_pmd res, *orig = (union pmd_parts *)pmdp; + +/* xchg acts as a barrier before setting of the high bits */ + res.pmd_low =xchg (&orig->pmd_low,0 ); + res.pmd_high = orig->pmd_high; + orig->pmd_high =0 ; + +return res.pmd; +} +#else +#define native_pmdp_get_and_clear (xp) native_local_pmdp_get_and_clear(xp) +#endif +/* * Bits 0, 6 and 7 are taken in the low part of the pte, * put the 32 bits of offset into the high part.
arch/x86/include/asm/pgtable.h +117 -0
147 lines not on this page · raw message
arch/x86/include/asm/pgtable_64.h +0 -109
115 lines not on this page · raw message
arch/x86/mm/pgtable.c +2 -2
@@ -351,7 +351,7 @@ int pmdp_test_and_clear_young(struct vm_if (pmd_young (*pmdp)) ret =test_and_clear_bit (_PAGE_BIT_ACCESSED, - (unsigned long *) &pmdp->pmd); + (unsigned long *)pmdp);if (ret)pmd_update (vma->vm_mm, addr, pmdp);
@@ -393,7 +393,7 @@ void pmdp_splitting_flush(struct vm_areaint set;VM_BUG_ON (address & ~HPAGE_PMD_MASK ); set = !test_and_set_bit (_PAGE_BIT_SPLITTING, - (unsigned long *)&pmdp->pmd); + (unsigned long *)pmdp);if (set) {pmd_update (vma->vm_mm, address, pmdp);/* need tlb flush only to serialize against gup-fast */
include/linux/mm.h +4 -3
@@ -98,7 +98,11 @@ extern unsigned int kobjsize(const void#define VM_NORESERVE 0x00200000/* should the VM suppress accounting */ #define VM_HUGETLB 0x00400000/* Huge TLB Page VM */ #define VM_NONLINEAR 0x00800000/* Is non-linear (remap_file_pages) */ +#ifndef CONFIG_TRANSPARENT_HUGEPAGE #define VM_MAPPED_COPY 0x01000000/* T if mapped copy of data (nommu mmap) */ +#else +#define VM_HUGEPAGE 0x01000000/* MADV_HUGEPAGE marked this vma */ +#endif #define VM_INSERTPAGE 0x02000000/* The vma has had "vm_insert_page()" done on it */ #define VM_ALWAYSDUMP 0x04000000/* Always include in core dumps */
@@ -107,9 +111,6 @@ 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
mm/Kconfig +1 -1
@@ -290,7 +290,7 @@ config NOMMU_INITIAL_TRIM_EXCESS config TRANSPARENT_HUGEPAGE bool "Transparent Hugepage support" if EMBEDDED - depends on X86_64 + depends on X86 default y help Transparent Hugepages allows the kernel to use huge pages and
--
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 37 of 41] add x86 32bit support
Quoted 9 lines · Andrea Arcangeli
From: Andrea Arcangeli<[email protected]>
Add support for transparent hugepages to x86 32bit.
Share the same
VM_bitflag forVM_MAPPED_COPY.mm/nommu.cwill never support transparent hugepages.Signed-off-by Johannes Weiner<[email protected]>Signed-off-by Andrea Arcangeli<[email protected]>
--
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>
Johannes Weiner
maintainerRe: [PATCH 37 of 41] add x86 32bit support
In reply to Andrea ArcangeliQuoted 8 lines · Andrea Arcangeli
arch/x86/include/asm/pgtable-3level.h +1
-0@@ -104,6 +104,29 @@ static inline pte_t native_ptep_get_and_#define native_ptep_get_and_clear (xp) native_local_ptep_get_and_clear(xp)#endif +#ifdef CONFIG_SMP
arch/x86/include/asm/pgtable-3level.h static inline pte_t native_ptep_get_and_ · line 117
Quoted 10 lines
arch/x86/include/asm/pgtable-3level.h +10
-0+union split_pmd { +struct { +u32 pmd_low; +u32 pmd_high; + }; +pmd_t pmd; +}; +static inline pmd_t native_pmdp_get_and_clear (pmd_t *pmdp) +{ +union split_pmd res, *orig = (union pmd_parts *)pmdp;
Oh, shoot, the cast needs to be renamed to (union split_pmd *) as well.
Hannes
--
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 37 of 41] add x86 32bit support
Quoted 1 line · Johannes Weiner
Oh, shoot, the cast needs to be renamed to (union
split_pmd*) as well.
I only verified x86 builds without PAE, I fixed that bit now and verified it gets past it. However it still doesn't build because PG_compound_lock exceeds the 32bit page->flags (with zone and other stuff). I don't immediately see PG_ bits to reuse, but I think PageBuddy can be converted to page->_count = -1. For now the only way to build PAE on x86 with hugepages enabled, it is to set
PAT=n. Considering that the only way to disable transparent hugepages is to enable the embedded settings in the config, it isn't such great but again I'm optimistic we can drop PG_buddy. PG_reclaim is very dubious too but as long as we want to retain that functionality of trying to free pages after swapout I/O completion immediately, there's no way to keep functionality removing PG_reclaim. Others are similar...
--
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)
The fundamental reason why khugepaged is unavoidable, is that some memory can be fragmented and not everything can be relocated. So when a virtual machine quits and releases gigabytes of hugepages, we want to use those freely available hugepages to create huge-pmd in the other virtual machines that may be running on fragmented memory, to maximize the CPU efficiency at all times. The scan is slow, it takes nearly zero cpu time, except when it copies data (in which case it means we definitely want to pay for that cpu time) so it seems a good tradeoff.
In addition to the hugepages being released by other process releasing memory, we have the strong suspicion that the performance impact of potentially defragmenting hugepages during or before each page fault could lead to more performance inconsistency than allocating small pages at first and having them collapsed into large pages later... if they prove themselfs to be long lived mappings (khugepaged scan is slow so short lived mappings have low probability to run into khugepaged if compared to long lived mappings).
---
include/linux/huge_mm.h +3 -0
@@ -23,8 +23,11 @@ extern int zap_huge_pmd(struct mmu_gatheenum transparent_hugepage_flag {TRANSPARENT_HUGEPAGE_FLAG ,TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG , +TRANSPARENT_HUGEPAGE_KHUGEPAGED_FLAG , +TRANSPARENT_HUGEPAGE_KHUGEPAGED_REQ_MADV_FLAG ,TRANSPARENT_HUGEPAGE_DEFRAG_FLAG ,TRANSPARENT_HUGEPAGE_DEFRAG_REQ_MADV_FLAG , +TRANSPARENT_HUGEPAGE_DEFRAG_KHUGEPAGED_FLAG ,#ifdef CONFIG_DEBUG_VM TRANSPARENT_HUGEPAGE_DEBUG_COW_FLAG ,#endif
include/linux/khugepaged.h new file +66 -0
66 lines not on this page · raw message
include/linux/sched.h +1 -0
@@ -435,6 +435,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>
@@ -327,6 +328,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;
@@ -539,6 +543,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 +1097 -7
1,149 lines not on this page · raw message
mm/mmap.c +3 -0
@@ -28,6 +28,7 @@#include <linux/rmap.h> #include <linux/mmu_notifier.h> #include <linux/perf_event.h> +#include <linux/khugepaged.h> #include <asm/uaccess.h> #include <asm/cacheflush.h>
@@ -800,6 +801,7 @@ struct vm_area_struct *vma_merge(struct end, prev->vm_pgoff, NULL);if (err)return NULL ; +khugepaged_enter_vma_merge (prev);return prev; }
@@ -818,6 +820,7 @@ struct vm_area_struct *vma_merge(struct next->vm_pgoff - pglen, NULL);if (err)return NULL ; +khugepaged_enter_vma_merge (area);return area; }
--
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
@@ -310,6 +310,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
@@ -522,6 +522,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);
@@ -662,6 +665,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>
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
@@ -225,6 +225,7 @@ static int __do_huge_pmd_anonymous_page(VM_BUG_ON (!PageCompound (page)); pgtable =pte_alloc_one (mm, haddr);if (unlikely (!pgtable)) { +mem_cgroup_uncharge_page (page);put_page (page);return VM_FAULT_OOM ; }
@@ -235,6 +236,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 {
@@ -278,6 +280,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, haddr, pmd, page); }
@@ -377,9 +383,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;
@@ -438,8 +450,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; }
@@ -482,13 +496,19 @@ 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);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>
PATCH 1/1 memcg compound
In reply to Andrea ArcangeliFrom: Andrea Arcangeli <[email protected]>
Teach memcg to charge/uncharge compound pages.
---
Documentation/cgroups/memory.txt +4 -0
@@ -4,6 +4,10 @@ NOTE: The Memory Resource Controller has to as the memory controller in this document. Do not confuse memory controller used here with the memory controller that is used in hardware. +NOTE: When in this documentation we refer to PAGE_SIZE, we actually +mean the real page size of the page being accounted which is bigger than +PAGE_SIZE for compound pages. + Salient features a. Enable control of Anonymous, Page Cache (mapped and unmapped) and
mm/memcontrol.c +50 -33
249 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 41] memcg compound
mm/memcontrol.c
Quoted 25 lines · Andrea Arcangeli
From: Andrea Arcangeli <[email protected]>
Teach memcg to charge/uncharge compound pages.
Signed-off-by Andrea Arcangeli <[email protected]>Acked-by Rik van Riel <[email protected]>---
Documentation/cgroups/memory.txt +4
-0@@ -4,6 +4,10 @@ NOTE: The Memory Resource Controller has to as the memory controller in this document. Do not confuse memory controller used here with the memory controller that is used in hardware. +NOTE: When in this documentation we refer to PAGE_SIZE, we actually +mean the real page size of the page being accounted which is bigger than +PAGE_SIZE for compound pages. + Salient features a. Enable control of Anonymous, Page Cache (mapped and unmapped) andmm/memcontrol.c +0
-0
I'm afraid, I get confused by these changes to __mem_cgroup_try_charge().
You want to charge by @page_size, right ? Then, I think you should initialize "csize" first as:
csize = max(CHARGE_SIZE, page_size);
Quoted 35 lines
mm/memcontrol.c +8
-5@@ -1577,7 +1577,9 @@ 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) +gfp_t gfp_mask, +struct mem_cgroup **memcg,bool oom, +int page_size) {struct mem_cgroup *mem, *mem_over_limit;int nr_retries =MEM_CGROUP_RECLAIM_RETRIES ;@@ -1617,8 +1619,9 @@ static int __mem_cgroup_try_charge(strucint ret =0 ;unsigned long flags =0 ; -if (consume_stock (mem)) - goto done; +if (page_size ==PAGE_SIZE ) +if (consume_stock (mem)) + goto done; ret =res_counter_charge (&mem->res, csize, &fail_res);if (likely (!ret)) {@@ -1638,8 +1641,8 @@ static int __mem_cgroup_try_charge(struc res);/* reduce request size and retry */ -if (csize >PAGE_SIZE ) { - csize =PAGE_SIZE ; +if (csize > page_size) { + csize = page_size;continue ; }if (!(gfp_mask & __GFP_WAIT))
mm/memcontrol.c static int __mem_cgroup_try_charge(struc · line 1725
Quoted 10 lines
mm/memcontrol.c +2
-2@@ -1715,8 +1718,8 @@ static int __mem_cgroup_try_charge(struc goto bypass; } } -if (csize >PAGE_SIZE ) -refill_stock (mem, csize -PAGE_SIZE ); +if (csize > page_size) +refill_stock (mem, csize - page_size); done:return 0 ; nomem:
And __mem_cgroup_cancel_charge() puts the css by its @count, so you need additional css_get() in __mem_cgroup_try_charge() in case of "page_size != PAGE_SIZE".
So, I think __mem_cgroup_try_charge() needs the change like:
@@ -1582,12 +1582,13 @@ static int __cpuinit memcg_stock_cpu_callback(struct notifier_block *nb,
* 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)
+ gfp_t gfp_mask, struct mem_cgroup **memcg,
+ bool oom, int page_size)
{
struct mem_cgroup *mem, *mem_over_limit;
int nr_retries = MEM_CGROUP_RECLAIM_RETRIES;
struct res_counter *fail_res;
- int csize = CHARGE_SIZE;
+ int csize = max(CHARGE_SIZE, page_size);
/*
* Unlike gloval-vm's OOM-kill, we're not in memory shortage
@@ -1622,8 +1623,9 @@ static int __mem_cgroup_try_charge(struct mm_struct *mm,
int ret = 0;
unsigned long flags = 0;
- if (consume_stock(mem))
- goto done;
+ if (page_size == PAGE_SIZE)
+ if (consume_stock(mem))
+ goto done;
ret = res_counter_charge(&mem->res, csize, &fail_res); if (likely(!ret)) {
@@ -1643,8 +1645,8 @@ static int __mem_cgroup_try_charge(struct mm_struct *mm,
res);
/* reduce request size and retry */
- if (csize > PAGE_SIZE) {
- csize = PAGE_SIZE;
+ if (csize > page_size) {
+ csize = page_size;
continue;
}
if (!(gfp_mask & __GFP_WAIT))
@@ -1720,8 +1722,10 @@ static int __mem_cgroup_try_charge(struct mm_struct *mm,
goto bypass;
}
}
- if (csize > PAGE_SIZE)
- refill_stock(mem, csize - PAGE_SIZE);
+ if (csize > page_size)
+ refill_stock(mem, csize - page_size);
+ if (page_size != PAGE_SIZE)
+ __css_get(&mem->css, page_size >> PAGE_SHIFT - 1);
done:
return 0;
nomem:
Thanks,
Daisuke Nishimura.
Quoted 230 lines
mm/memcontrol.c +40
-27@@ -1746,9 +1749,10 @@ static void __mem_cgroup_cancel_charge(s/* we don't need css_put for root */ } -static void mem_cgroup_cancel_charge (struct mem_cgroup *mem) +static void mem_cgroup_cancel_charge (struct mem_cgroup *mem, +int page_size) { -__mem_cgroup_cancel_charge (mem,1 ); +__mem_cgroup_cancel_charge (mem, page_size >>PAGE_SHIFT ); }/* @@ -1804,8 +1808,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)@@ -1814,7 +1819,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 ; }@@ -1891,7 +1896,7 @@ static void __mem_cgroup_move_account(stmem_cgroup_charge_statistics (from, pc, false);if (uncharge)/* This is not "cancel", but cancel_charge does all we need. */ -mem_cgroup_cancel_charge (from); +mem_cgroup_cancel_charge (from,PAGE_SIZE );/* caller should have done css_get */ pc->mem_cgroup = to;@@ -1952,13 +1957,14 @@ 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); + ret =__mem_cgroup_try_charge (NULL , gfp_mask, &parent, false, +PAGE_SIZE );if (ret || !parent) goto put_back; ret =mem_cgroup_move_account (pc, child, parent, true);if (ret) -mem_cgroup_cancel_charge (parent); +mem_cgroup_cancel_charge (parent,PAGE_SIZE ); put_back:putback_lru_page (page); put:@@ -1980,6 +1986,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 */ @@ -1988,11 +1998,11 @@ static int mem_cgroup_charge_common(struprefetchw (pc); mem = memcg; - ret =__mem_cgroup_try_charge (mm, gfp_mask, &mem, true); + ret =__mem_cgroup_try_charge (mm, gfp_mask, &mem, true, 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 ; }@@ -2001,8 +2011,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. @@ -2015,7 +2023,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@@ -2108,14 +2116,14 @@ int mem_cgroup_try_charge_swapin(structif (!mem) goto charge_cur_mm; *ptr = mem; - ret =__mem_cgroup_try_charge (NULL , mask, ptr, true); + ret =__mem_cgroup_try_charge (NULL , mask, ptr, true,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); +return __mem_cgroup_try_charge (mm, mask, ptr, true,PAGE_SIZE ); } static void@@ -2131,7 +2139,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 @@ -2180,11 +2188,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;@@ -2219,14 +2228,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);if (unlikely (batch->memcg != mem))memcg_oom_recover (mem);return ;@@ -2241,6 +2250,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 ;@@ -2280,7 +2293,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);@@ -2506,7 +2519,8 @@ int mem_cgroup_prepare_migration(structunlock_page_cgroup (pc);if (mem) { - ret =__mem_cgroup_try_charge (NULL ,GFP_KERNEL , &mem, false); + ret =__mem_cgroup_try_charge (NULL ,GFP_KERNEL , &mem, false, +PAGE_SIZE );css_put (&mem->css); } *ptr = mem;@@ -2549,7 +2563,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(). @@ -4144,7 +4158,8 @@ one_by_one: batch_count =PRECHARGE_COUNT_AT_ONCE ;cond_resched (); } - ret =__mem_cgroup_try_charge (NULL ,GFP_KERNEL , &mem, false); + ret =__mem_cgroup_try_charge (NULL ,GFP_KERNEL , &mem, false, +PAGE_SIZE );if (ret || !mem)/* mem_cgroup_clear_mc() will do uncharge later */ return -ENOMEM ;@@ -4259,6 +4274,7 @@ static int mem_cgroup_count_precharge_ptpte_t *pte;spinlock_t *ptl; +VM_BUG_ON (pmd_trans_huge (*pmd)); pte =pte_offset_map_lock (vma->vm_mm, pmd, addr, &ptl);for (; addr != end; pte++, addr +=PAGE_SIZE )if (is_target_pte_for_mc (vma, addr, *pte,NULL ))@@ -4407,6 +4423,7 @@ static int mem_cgroup_move_charge_pte_raspinlock_t *ptl; retry: +VM_BUG_ON (pmd_trans_huge (*pmd)); pte =pte_offset_map_lock (vma->vm_mm, pmd, addr, &ptl);for (; addr != end; addr +=PAGE_SIZE ) {pte_t ptent = *(pte++); --
Quoted 4 lines
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>
--
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 41] memcg compound
Review
Quoted 1 line · Daisuke Nishimura
(quoted diff) +1
-0+ int csize = max(CHARGE_SIZE, page_size);
I had to cast page_size to unsigned long to shut off an harmless warning. Hopefully all archs defines PAGE_SIZE as UL.
Quoted 1 line
Thanks,
Thanks to you for spotting the two issues.
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>
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 +4 -4
@@ -300,15 +300,15 @@ pmd_t *populate_extra_pmd(unsigned longpte_t *populate_extra_pte (unsigned long vaddr);#endif /* __ASSEMBLY__ */ +#ifndef __ASSEMBLY__ +#include <linux/mm_types.h> +#ifdef CONFIG_X86_32 # include "pgtable_32.h" #else # include "pgtable_64.h" #endif -#ifndef __ASSEMBLY__ -#include <linux/mm_types.h> -static inline int pte_none (pte_t pte) {return !pte.pte;
@@ -351,7 +351,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]
arch/x86/include/asm/pgtable_64.h +105 -0
117 lines not on this page · raw message
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>
PATCH 1/1 mprotect: transparent huge page support
In reply to Andrea ArcangeliFrom: Johannes Weiner <[email protected]>
Natively handle huge pmds when changing page tables on behalf of mprotect().
I left out update_mmu_cache() because we do not need it on x86 anyway but more importantly the interface works on ptes, not pmds.
---
include/linux/huge_mm.h +2 -0
@@ -22,6 +22,8 @@ extern int zap_huge_pmd(struct mmu_gatheextern int mincore_huge_pmd (struct vm_area_struct *vma,pmd_t *pmd,unsigned long addr,unsigned long end,unsigned char *vec); +extern int change_huge_pmd (struct vm_area_struct *vma,pmd_t *pmd, +unsigned long addr,pgprot_t newprot);enum transparent_hugepage_flag {TRANSPARENT_HUGEPAGE_FLAG ,
mm/huge_memory.c +27 -0
@@ -961,6 +961,33 @@ int mincore_huge_pmd(struct vm_area_strureturn ret; } +int change_huge_pmd (struct vm_area_struct *vma,pmd_t *pmd, +unsigned long addr,pgprot_t newprot) +{ +struct mm_struct *mm = vma->vm_mm; +int ret =0 ; + +spin_lock (&mm->page_table_lock); +if (likely (pmd_trans_huge (*pmd))) { +if (unlikely (pmd_trans_splitting (*pmd))) { +spin_unlock (&mm->page_table_lock); +wait_split_huge_page (vma->anon_vma, pmd); + }else { +pmd_t entry; + + entry =pmdp_get_and_clear (mm, addr, pmd); + entry =pmd_modify (entry, newprot); +set_pmd_at (mm, addr, pmd, entry); +spin_unlock (&vma->vm_mm->page_table_lock); +flush_tlb_range (vma, addr, addr +HPAGE_PMD_SIZE ); + ret =1 ; + } + }else +spin_unlock (&vma->vm_mm->page_table_lock); + +return ret; +} + pmd_t *page_check_address_pmd(struct page *page, struct mm_struct *mm, unsigned long address,
mm/mprotect.c +7 -1
@@ -90,7 +90,13 @@ static inline void change_pmd_range(stru pmd =pmd_offset (pud, addr); do { next = pmd_addr_end(addr, end); - split_huge_page_pmd(vma->vm_mm, pmd); + if (pmd_trans_huge(*pmd)) { + if (next - addr != HPAGE_PMD_SIZE) + split_huge_page_pmd(vma->vm_mm, pmd); + else if (change_huge_pmd(vma, pmd, addr, newprot)) + continue; + /* fall through */ + } if (pmd_none_or_clear_bad(pmd)) continue; change_pte_range(vma, pmd, addr, next, newprot, dirty_accountable);
--
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 41 of 41] mprotect: transparent huge page support
Quoted 10 lines · Andrea Arcangeli
From: Johannes Weiner<[email protected]>
Natively handle huge pmds when changing page tables on behalf of
mprotect().I left out
update_mmu_cache()because we do not need it on x86 anyway but more importantly the interface works on ptes, not pmds.Signed-off-by Johannes Weiner<[email protected]>Signed-off-by Andrea Arcangeli<[email protected]>
--
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
@@ -105,6 +105,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 HPAGE_PMD_SHIFT ({ BUG(); 0; })#define HPAGE_PMD_MASK ({ BUG(); 0; })
@@ -122,6 +126,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
@@ -94,6 +94,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;
@@ -810,6 +811,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>
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;
}============
---
* * *
adapt to mm_counter in -mm
From: Andrea Arcangeli <[email protected]>
The interface changed slightly.
---
arch/x86/include/asm/pgtable_64.h +5 -0
@@ -286,6 +286,11 @@ static inline pmd_t pmd_mkwrite(pmd_t pmreturn pmd_set_flags (pmd, _PAGE_RW); } +static inline pmd_t pmd_mknotpresent (pmd_t pmd) +{ +return pmd_clear_flags (pmd, _PAGE_PRESENT); +} +#endif /* !__ASSEMBLY__ */ #endif /* _ASM_X86_PGTABLE_64_H */
include/linux/gfp.h +3 -0
@@ -87,6 +87,9 @@ struct vm_area_struct; __GFP_HARDWALL | __GFP_HIGHMEM | \ __GFP_MOVABLE)#define GFP_IOFS (__GFP_IO | __GFP_FS) +#define GFP_TRANSHUGE (__GFP_HARDWALL | __GFP_HIGHMEM | \ + __GFP_MOVABLE | __GFP_COMP | __GFP_NOMEMALLOC | \ + __GFP_NORETRY | __GFP_NOWARN | __GFP_NO_KSWAPD)#ifdef CONFIG_NUMA #define GFP_THISNODE (__GFP_THISNODE | __GFP_NOWARN | __GFP_NORETRY)
include/linux/huge_mm.h new file +126 -0
126 lines not on this page · raw message
include/linux/mm.h +4 -0
@@ -107,6 +107,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
@@ -235,6 +238,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 +865 -0
865 lines not on this page · raw message
mm/memory.c +58 -7
105 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>
Quoted 19 lines · Andrea Arcangeli
Hello,
this fixes a potential issue with regard to simultaneous 4k and 2M TLB entries in
split_huge_page(at pratically zero cost, so I didn't need to add a fake feature flag and it's a lot safer to do it this way just in case).split_large_pageinchange_page_attrhas the same issue too, but I've no idea how to fix it there because the pmd cannot be marked non present at any given time aschange_page_attrmay be running on ram below 640k and that is the same pmd where the kernel .text resides. However I doubt it'll ever be a practical problem. Other cpus also has a lot of warnings and risks in allowing simultaneous TLB entries of different size.Johannes also sent a cute optimization to split split_huge_page_vma/mm he converted those in a single
split_huge_page_pmdand in addition he also sent native support for hugepages in both mincore and mprotect. Which shows how deep he already understands the wholehuge_memory.cand its usage in the callers. Seeing significant contributions like this I think further confirms this is the way to go. Thanks a lot Johannes.
Quoted 7 lines
The ability to bisect before the mincore and mprotect native implementations is one of the huge benefits of this approach. The hardest of all will be to add swap native support to 2M pages later (as it involves to make the swapcache 2M capable and that in turn means it expodes more than the rest all over the pagecache code) but I think first we've other priorities:
1) merge memory compaction
Testing V6 at the moment.
Quoted 4 lines
2) writing a
HPAGE_PMD_ORDERfront slab allocator. I don't think memory compaction is capable of relocating slab entries in-use (correct me if I'm wrong, I think it's impossible as long as the slab entries are mapped by 2M pages and not 4k ptes like vmalloc).So the idea is that we should have the
Correct, slab pages currently cannot migrate. Framentation within slab is minimised by anti-fragmentation by distinguishing between reclaimable and unreclaimable slab and grouping them appropriately. The objective is to put all the unmovable pages in as few 2M (or 4M or 16M) pages as possible. If min_free_kbytes is tuned as hugeadm --recommended-min_free_kbytes suggests, this works pretty well.
Quoted 3 lines
slab allocate 2M if it fails, 1M if it fails 512k etc... until it fallbacks to 4k. Otherwise the slab will fragment the memory badly by allocating with
alloc_page().
Again, if min_free_kbytes is tuned appropriately, anti-frag should mitigate most of the fragmentation-related damage.
On the notion of having a 2M front slab allocator, SLUB is not far off being capable of such a thing but there are risks. If a 2M page is dedicated to a slab, then other slabs will need their own 2M pages. Overall memory usage grows and you end up worse off.
If you suggest that slab uses 2M pages and breaks them up for slabs, you are very close to what anti-frag already does. The difference might be that slab would guarantee that the 2M page is only use for slab. Again, you could force this situation with anti-frag but the decision was made to allow a certain amount of fragmentation to avoid the memory overhead of such a thing. Again, tuning min_free_kbytes + anti-fragmentation gets much of what you need.
Arguably, min_free_kbytes should be tuned appropriately once it's detected that huge pages are in use. It would not be hard at all, we just don't do it.
Stronger guarantees on layout are possible but not done today because of the cost.
Quoted 3 lines
Basically the buddy allocator will guarantee the slab will generate as much fragement as possible because it does its best to keep the high order pages for who asks for them.
Again, already does this up to a point. rmqueue_fallback() could refuse to break up small contiguous pages for slab to force better layout in terms of fragmentation but it costs heavily when memory is low because you now have to reclaim (or relocate) more pages than necessary to satisfy anti-fragmentation.
Quoted 8 lines
Probably the fallback should
happen inside the buddy allocator instead of callingalloc_pagesrepeteadly, that should avoid taking a flood of locks. Basically the buddy should give the worst possible fragmentation effect to users that should be relocated, while the other users that cannot be relocated and only use 4k pages will better use a front allocator on top ofalloc_pages. Something likealloc_page_not_relocatable()that will do its stuff internally and try to keep those in the same 2M pages.
Sounds very similar to anti-frag again.
Quoted 4 lines
This alone should
help tremendously and I think it's orthogonal to the memory compaction of the relocatable stuff. Or maybe we should just live with a large chunk of the memory not being relocatable,
You could force such a situation by always having X number of lower blocks MIGRATE_UNMOVABLE and forcing a situation where fallback never happens to those areas. You'd need to do some juggling with counters and watermarks. It's not impossible and I considered doing it when anti-fragmentation was introduced but again, there was insufficient data to support such a move.
Quoted 19 lines
but I like this idea because it's more
dynamic and it won't have fixed rule "limit the slab to 0-1g range". And it'd tend to try to keep fragmentation down even if we spill over the 1G range. (1g is purely made up number)
3) teach ksm to merge hugepages. I talked about this with Izik and we agree the current ksm tree algorithm will be the best at that compared to ksm algorithms.To run KVM on top on this and take advantage of hugepages you need a few liner patch I posted to qemu-devel to take care of aligning the start of the guest memory so that the guest physical address and host virtual address will have the same subpage numbers.
http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.6/2.6.34-rc2-mm1/transparent_hugepage-15 http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.6/2.6.34-rc2-mm1/transparent_hugepage-15.gzI'd be nice to have this merged in -mm.
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>
Quoted 6 lines · Mel Gorman
Correct, slab pages currently cannot migrate. Framentation within slab is minimised by anti-fragmentation by distinguishing between reclaimable and unreclaimable slab and grouping them appropriately. The objective is to put all the unmovable pages in as few 2M (or 4M or 16M) pages as possible. If
min_free_kbytesis tuned as hugeadm --recommended-min_free_kbytes suggests, this works pretty well.
Awesome. So this feature is already part of your memory compaction code? As you may have noticed I didn't start looking deep on your code yet.
Quoted 2 lines
Again, if
min_free_kbytesis tuned appropriately, anti-frag should mitigate most of the fragmentation-related damage.
I don't see the relation of why this logic should be connected to min_free_kbytes. Maybe I'll get it if I read the code. But min_free_kbytes is about the PF_MEMALLOC pool and GFP_ATOMIC memory. I can't see any connection with min_free_kbytes setting, and in to trying to keep all non relocatable entries in the same HPAGE_PMD_SIZEd pages.
Quoted 7 lines
On the notion of having a 2M front slab allocator, SLUB is not far off being capable of such a thing but there are risks. If a 2M page is dedicated to a slab, then other slabs will need their own 2M pages. Overall memory usage grows and you end up worse off.
If you suggest that slab uses 2M pages and breaks them up for slabs, you are very close to what anti-frag already does. The difference might be
That's exactly what I meant yes. Doing it per-slab would be useless.
The idea was for slub to simply call alloc_page_not_relocatable(order) instead of alloc_page() every time it allocates an order <= HPAGE_PMD_ORDER. That means this 2M page would be shared for _all_ slabs, otherwise it wouldn't work.
The page freeing could even go back in the buddy initially. So the max waste would be 2M per cpu of ram (the front page has to be per-cpu to perform).
Quoted 5 lines
that slab would guarantee that the 2M page is only use for slab. Again, you could force this situation with anti-frag but the decision was made to allow a certain amount of fragmentation to avoid the memory overhead of such a thing. Again, tuning
min_free_kbytes+ anti-fragmentation gets much of what you need.
Well if this 2M page is shared by other not relocatable entities that might be even better in some scenario (maybe worse in others) but I'm totally fine with a more elaborate approach. Clearly some driver could also start to call alloc_pages_not_relocatable() and then it'd also share the same memory as slab. I think it has to be an universally available feature, just like you implemented. Except right now the main problem is slab so that's the first user for sure ;).
Quoted 5 lines
Arguably,
min_free_kbytesshould be tuned appropriately once it's detected that huge pages are in use. It would not be hard at all, we just don't do it.Stronger guarantees on layout are possible but not done today because of the cost.
Could you elaborate what "guarantees of layout" means?
Quoted 9 lines
Quoted 4 lines
Basically the buddy allocator will guarantee the slab will generate as much fragement as possible because it does its best to keep the high order pages for who asks for them.
Again, already does this up to a point.
rmqueue_fallback()could refuse to break up small contiguous pages for slab to force better layout in terms of fragmentation but it costs heavily when memory is low because you now have to reclaim (or relocate) more pages than necessary to satisfy anti-fragmentation.
I guess this will require a sysfs control. Do you have a /sys/kernel/mm/defrag directory or something? If hugepages are absolutely mandatory (like with hypervisor-only usage) it is worth invoking memory compaction to satisfy what i call "front allocator" and give a full 2M page to slab instead of using the already available fragment. And to rmqueue-fallback only if defrag fails.
Quoted 1 line
Sounds very similar to anti-frag again.
Indeed.
Quoted 5 lines
You could force such a situation by always having X number of lower blocks
MIGRATE_UNMOVABLEand forcing a situation where fallback never happens to those areas. You'd need to do some juggling with counters and watermarks. It's not impossible and I considered doing it when anti-fragmentation was introduced but again, there was insufficient data to support such a move.
Agreed. I also like a more dynamic approach, the whole idea of transparent hugepage is that the admin does nothing, no reservation, and in this case no decision of how much memory to be MIGRATE_UNMOVABLE.
Looking forward to see transparent hugepage taking full advantage of your patchset!
Thanks,
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>
Quoted 10 lines · Andrea Arcangeli
Quoted 6 lines · Mel Gorman
Correct, slab pages currently cannot migrate. Framentation within slab is minimised by anti-fragmentation by distinguishing between reclaimable and unreclaimable slab and grouping them appropriately. The objective is to put all the unmovable pages in as few 2M (or 4M or 16M) pages as possible. If
min_free_kbytesis tuned as hugeadm --recommended-min_free_kbytes suggests, this works pretty well.Awesome. So this feature is already part of your memory compaction code?
No, anti-fragmentation has been in a long time. hugeadm (part of libhugetlbfs) has supported --recommended-min_free_kbytes for some time as well.
Quoted 6 lines
As you may have noticed I didn't start looking deep on your code yet.
Quoted 2 lines
Again, if
min_free_kbytesis tuned appropriately, anti-frag should mitigate most of the fragmentation-related damage.
Quoted 7 lines
I don't see the relation of why this logic should be connected to
min_free_kbytes. Maybe I'll get it if I read the code. Butmin_free_kbytesis about thePF_MEMALLOCpool andGFP_ATOMICmemory. I can't see any connection withmin_free_kbytessetting, and in to trying to keep all non relocatable entries in the sameHPAGE_PMD_SIZEdpages.
Anti-fragmentation groups within pageblocks that are the size of the default huge page size. Blocks can have different migratetypes and the free lists are also based on types. If there isn't a free page of the appropriate type, rmqueue_fallback() selects an alternative list to use from. Each one of these "fallback" events potentially increases the badness of the level of fragmentation.
Using --recommended-min_free_kbytes keeps a number of pages free such that these "fallback" events are severely reduced because there is typically a page free of the appropriate type located in the correct pageblock.
If you were very curious, you use the mm_page_alloc_extfrag trace event to monitor fragmentation-related events. Part of the event reports "fragmenting=" which indicates whether the fallback is severe in terms of fragmentation or not.
Quoted 11 lines
Quoted 7 lines
On the notion of having a 2M front slab allocator, SLUB is not far off being capable of such a thing but there are risks. If a 2M page is dedicated to a slab, then other slabs will need their own 2M pages. Overall memory usage grows and you end up worse off.
If you suggest that slab uses 2M pages and breaks them up for slabs, you are very close to what anti-frag already does. The difference might be
That's exactly what I meant yes. Doing it per-slab would be useless.
The idea was for slub to simply call
alloc_page_not_relocatable(order)
If you don't specify migratetype-related GFP flags, it's assumed to be UNMOVABLE.
Quoted 4 lines
instead of
alloc_page()every time it allocates an order <=HPAGE_PMD_ORDER. That means this 2M page would be shared for _all_ slabs, otherwise it wouldn't work.
I still think anti-frag is already doing most of what you suggest. Slab should already be using UNMOVABLE blocks (See /proc/pagetypeinfo for how the pageblocks are being used).
Quoted 4 lines
The page freeing could even go back in the buddy initially. So the max waste would be 2M per cpu of ram (the front page has to be per-cpu to perform).
Quoted 8 lines
Quoted 5 lines
that slab would guarantee that the 2M page is only use for slab. Again, you could force this situation with anti-frag but the decision was made to allow a certain amount of fragmentation to avoid the memory overhead of such a thing. Again, tuning
min_free_kbytes+ anti-fragmentation gets much of what you need.Well if this 2M page is shared by other not relocatable entities that might be even better in some scenario (maybe worse in others)
The 2M page is today being shared with other unmovable (what you call not relocatable) pages. The scenario where it potentially gets worse is where there is a weird mix of pagetable and slab allocations. This will push up the number of blocks used for unmovable pages to some extent.
Quoted 7 lines
but
I'm totally fine with a more elaborate approach. Clearly some driver could also start to callalloc_pages_not_relocatable()and then it'd also share the same memory as slab. I think it has to be an universally available feature, just like you implemented. Except right now the main problem is slab so that's the first user for sure ;).
Right now, allocations are assumed to be unmovable unless otherwise specified.
Quoted 8 lines
Quoted 5 lines
Arguably,
min_free_kbytesshould be tuned appropriately once it's detected that huge pages are in use. It would not be hard at all, we just don't do it.Stronger guarantees on layout are possible but not done today because of the cost.
Could you elaborate what "guarantees of layout" means?
The ideal would be the fewest number of pageblocks are in use and each pageblock only contains the pages of a specific migratetype.
One "guaranteed layout" would be that pageblocks only ever contain pages of a given type but this would potentially require a full 2M of data to be relocated or reclaimed to satisfy a new allocation. It would also cause problems with atomics. It would be great from a fragmentation perspective but suck otherwise.
Quoted 11 lines
Quoted 9 lines
Quoted 4 lines
Basically the buddy allocator will guarantee the slab will generate as much fragement as possible because it does its best to keep the high order pages for who asks for them.
Again, already does this up to a point.
rmqueue_fallback()could refuse to break up small contiguous pages for slab to force better layout in terms of fragmentation but it costs heavily when memory is low because you now have to reclaim (or relocate) more pages than necessary to satisfy anti-fragmentation.I guess this will require a sysfs control.
It would also be a new feature. With memory compaction, the page allocator will compact memory to satisfy a high-order allocation but it doesn't compact memory to avoid mixing pageblocks.
Quoted 7 lines
Do you have a
/sys/kernel/mm/defragdirectory or something?> If hugepages are absolutely mandatory (like with hypervisor-only usage) it is worth invoking memory compaction to satisfy what i call "front allocator" and give a full 2M page to slab instead of using the already available fragment. And to rmqueue-fallback only if defrag fails.
There is a proc entry and sysfs entry that allow to compact either all of memory or on a per-node basis but I'd be surprised if it was required. When a new machine starts up, it should start direct-compacting memory to get the huge pages it needs.
Quoted 10 lines
Quoted 1 line
Sounds very similar to anti-frag again.
Indeed.
Quoted 5 lines
You could force such a situation by always having X number of lower blocks
MIGRATE_UNMOVABLEand forcing a situation where fallback never happens to those areas. You'd need to do some juggling with counters and watermarks. It's not impossible and I considered doing it when anti-fragmentation was introduced but again, there was insufficient data to support such a move.
Quoted 8 lines
Agreed. I also like a more dynamic approach, the whole idea of transparent hugepage is that the admin does nothing, no reservation, and in this case no decision of how much memory to be
MIGRATE_UNMOVABLE.Looking forward to see transparent hugepage taking full advantage of your patchset!
Same here.
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>
Quoted 3 lines · Andrea Arcangeli
2) writing a
HPAGE_PMD_ORDERfront slab allocator. I don't think memory compaction is capable of relocating slab entries in-use (correct me if I'm wrong, I think it's impossible as long as the slab entries are mapped by 2M
SLUB is capable of using huge pages. Specify slub_min_order=9 on boot and it will make the kernel use huge pages.
Quoted 6 lines
pages and not 4k ptes like vmalloc). So the idea is that we should have the slab allocate 2M if it fails, 1M if it fails 512k etc... until it fallbacks to 4k. Otherwise the slab will fragment the memory badly by allocating with
alloc_page(). Basically the buddy allocator will guarantee the slab will generate as much fragement as possible because it does its best to keep the high order pages for who asks for them. Probably the fallback should
Fallback is another issue. SLUB can handle various orders of pages in the same slab cache and already implements fallback to order 0. To implement a scheme as you suggest here would not require any changes to data structures but only to the slab allocation functions. See allocate_slab() in mm/slub.c
--
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 16 lines · Christoph Lameter
Quoted 3 lines · Andrea Arcangeli
2) writing a
HPAGE_PMD_ORDERfront slab allocator. I don't think memory compaction is capable of relocating slab entries in-use (correct me if I'm wrong, I think it's impossible as long as the slab entries are mapped by 2MSLUB is capable of using huge pages. Specify slub_min_order=9 on boot and it will make the kernel use huge pages.
Quoted 6 lines
pages and not 4k ptes like vmalloc). So the idea is that we should have the slab allocate 2M if it fails, 1M if it fails 512k etc... until it fallbacks to 4k. Otherwise the slab will fragment the memory badly by allocating with
alloc_page(). Basically the buddy allocator will guarantee the slab will generate as much fragement as possible because it does its best to keep the high order pages for who asks for them. Probably the fallback should
Quoted 5 lines
Fallback is another issue. SLUB can handle various orders of pages in the same slab cache and already implements fallback to order 0. To implement a scheme as you suggest here would not require any changes to data structures but only to the slab allocation functions. See
allocate_slab()inmm/slub.c
Thanks for the information! Luckily it seems Mel already taken care of this part in his patchset. But in my view, this feature should be available outside of SLUB/SLAB and potentially available to drivers and such. SLUB having this embedded is nice to know!!!
BTW, unfortunately according to tons of measurements done so far, SLUB is too slow on most workstations and small/mid servers (usually single digits but in some case even double digits percentage slowdowns depending on the workload, hackbench tends to stress it the most). It's a tradeoff between avoiding wasting tons of ram on 1024-way and running fast. Either that or something's wrong with SLUB implementation (and I'm talking about 2.6.32, no earlier code). I'd also like to save memory so it'd be great if SLUB can be fixed to perform faster!
--
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 9 lines · Andrea Arcangeli
BTW, unfortunately according to tons of measurements done so far, SLUB is too slow on most workstations and small/mid servers (usually single digits but in some case even double digits percentage slowdowns depending on the workload, hackbench tends to stress it the most). It's a tradeoff between avoiding wasting tons of ram on 1024-way and running fast. Either that or something's wrong with SLUB implementation (and I'm talking about 2.6.32, no earlier code). I'd also like to save memory so it'd be great if SLUB can be fixed to perform faster!
The SLUB fastpath is the fastest there is. Problems arise because of locality constraints in SLUB. SLAB can throw gobs of memory at it to guarantee a high cache hit rate but to cover all angles on NUMA requires to throw the gobs multiple times. The weakness is SLUBs free functions which frees the object directly to the slab page instead of running through a series of caching structures. If frees occur to locally dispersed objects then SLUB is at a disadvantage since its hitting cold cache lines for metadata on free.
On the other hand SLUB hands out objects in a locality aware fashion and not randomly from everywhere like SLAB. This is certainly good to reduce TLB pressure. Huge pages would accellerate SLUB since more objects can be served from the same page than before.
--
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 2 lines · Christoph Lameter
TLB pressure. Huge pages would accellerate SLUB since more objects can be served from the same page than before.
Agreed. I see it fallbacks to 4k instead of gradually going down, but that was my point, doing the fallback and entry alloc_pages N without internal buddy support would be fairly inefficient. This is why is suggest this logic to be outside of slab/slub, in theory even slab could be a bit faster thanks to large TLB on newly allocated slab objects. I hope Mel's code already takes care of all of this.
--
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 10 lines · Andrea Arcangeli
Quoted 2 lines · Christoph Lameter
TLB pressure. Huge pages would accellerate SLUB since more objects can be served from the same page than before.
Agreed. I see it fallbacks to 4k instead of gradually going down, but that was my point, doing the fallback and entry
alloc_pagesN without internal buddy support would be fairly inefficient. This is why is suggest this logic to be outside of slab/slub, in theory even slab could be a bit faster thanks to large TLB on newly allocated slab objects. I hope Mel's code already takes care of all of this.
SLAB's queueing system has the inevitable garbling effect on memory references. The larger the queues the larger that effect becomes.
We already have internal buddy support in the page allocator. Mel's defrag approach groups them together.
--
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>