From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: akpm@linux-foundation.org,
Mel Gorman <mgorman@techsingularity.net>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Vineet Gupta <Vineet.Gupta1@synopsys.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2] mm/thp/migration: switch from flush_tlb_range to flush_pmd_tlb_range
Date: Wed, 10 Feb 2016 21:44:07 +0530 [thread overview]
Message-ID: <87vb5wwnjk.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <1455118510-15031-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
> We remove one instace of flush_tlb_range here. That was added by
> f714f4f20e59ea6eea264a86b9a51fd51b88fc54 ("mm: numa: call MMU notifiers
> on THP migration"). But the pmdp_huge_clear_flush_notify should have
> done the require flush for us. Hence remove the extra flush.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> ---
> Changes from V1:
> * fix build error
>
> include/asm-generic/pgtable.h | 17 +++++++++++++++++
> mm/migrate.c | 8 +++++---
> mm/pgtable-generic.c | 14 --------------
> 3 files changed, 22 insertions(+), 17 deletions(-)
>
> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
> index c370b261c720..9401f4819891 100644
> --- a/include/asm-generic/pgtable.h
> +++ b/include/asm-generic/pgtable.h
> @@ -783,6 +783,23 @@ static inline int pmd_clear_huge(pmd_t *pmd)
> }
> #endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */
>
> +#ifndef __HAVE_ARCH_FLUSH_PMD_TLB_RANGE
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +/*
> + * ARCHes with special requirements for evicting THP backing TLB entries can
> + * implement this. Otherwise also, it can help optimize normal TLB flush in
> + * THP regime. stock flush_tlb_range() typically has optimization to nuke the
> + * entire TLB TLB if flush span is greater than a threshold, which will
> + * likely be true for a single huge page. Thus a single thp flush will
> + * invalidate the entire TLB which is not desitable.
> + * e.g. see arch/arc: flush_pmd_tlb_range
> + */
> +#define flush_pmd_tlb_range(vma, addr, end) flush_tlb_range(vma, addr, end)
> +#else
> +#define flush_pmd_tlb_range(vma, addr, end) BUILD_BUG()
> +#endif
> +#endif
> +
> #endif /* !__ASSEMBLY__ */
>
> #ifndef io_remap_pfn_range
> diff --git a/mm/migrate.c b/mm/migrate.c
> index b1034f9c77e7..c079c115d038 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -1767,7 +1767,10 @@ int migrate_misplaced_transhuge_page(struct mm_struct *mm,
> put_page(new_page);
> goto out_fail;
> }
> -
> + /*
> + * We are not sure a pending tlb flush here is for a huge page
> + * mapping or not. Hence use the tlb range variant
> + */
> if (mm_tlb_flush_pending(mm))
> flush_tlb_range(vma, mmun_start, mmun_end);
>
I was thinking we should be able to switch this flush_pmd_tlb_range. But
Kirill was not sure when we discussed this last time. Can we have a
pending tlb flush with PAGE_SIZE page translation, when we are parallely
trying to handle a autonuma fault on that ?
> @@ -1823,12 +1826,11 @@ fail_putback:
> page_add_anon_rmap(new_page, vma, mmun_start, true);
> pmdp_huge_clear_flush_notify(vma, mmun_start, pmd);
> set_pmd_at(mm, mmun_start, pmd, entry);
> - flush_tlb_range(vma, mmun_start, mmun_end);
> update_mmu_cache_pmd(vma, address, &entry);
>
> if (page_count(page) != 2) {
> set_pmd_at(mm, mmun_start, pmd, orig_entry);
> - flush_tlb_range(vma, mmun_start, mmun_end);
> + flush_pmd_tlb_range(vma, mmun_start, mmun_end);
> mmu_notifier_invalidate_range(mm, mmun_start, mmun_end);
> update_mmu_cache_pmd(vma, address, &entry);
> page_remove_rmap(new_page, true);
> diff --git a/mm/pgtable-generic.c b/mm/pgtable-generic.c
> index 9d4767698a1c..3c9c78400300 100644
> --- a/mm/pgtable-generic.c
> +++ b/mm/pgtable-generic.c
> @@ -84,20 +84,6 @@ pte_t ptep_clear_flush(struct vm_area_struct *vma, unsigned long address,
>
> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>
> -#ifndef __HAVE_ARCH_FLUSH_PMD_TLB_RANGE
> -
> -/*
> - * ARCHes with special requirements for evicting THP backing TLB entries can
> - * implement this. Otherwise also, it can help optimize normal TLB flush in
> - * THP regime. stock flush_tlb_range() typically has optimization to nuke the
> - * entire TLB TLB if flush span is greater than a threshhold, which will
> - * likely be true for a single huge page. Thus a single thp flush will
> - * invalidate the entire TLB which is not desitable.
> - * e.g. see arch/arc: flush_pmd_tlb_range
> - */
> -#define flush_pmd_tlb_range(vma, addr, end) flush_tlb_range(vma, addr, end)
> -#endif
> -
> #ifndef __HAVE_ARCH_PMDP_SET_ACCESS_FLAGS
> int pmdp_set_access_flags(struct vm_area_struct *vma,
> unsigned long address, pmd_t *pmdp,
> --
> 2.5.0
-aneesh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: akpm@linux-foundation.org,
Mel Gorman <mgorman@techsingularity.net>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Vineet Gupta <Vineet.Gupta1@synopsys.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2] mm/thp/migration: switch from flush_tlb_range to flush_pmd_tlb_range
Date: Wed, 10 Feb 2016 21:44:07 +0530 [thread overview]
Message-ID: <87vb5wwnjk.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <1455118510-15031-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
> We remove one instace of flush_tlb_range here. That was added by
> f714f4f20e59ea6eea264a86b9a51fd51b88fc54 ("mm: numa: call MMU notifiers
> on THP migration"). But the pmdp_huge_clear_flush_notify should have
> done the require flush for us. Hence remove the extra flush.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> ---
> Changes from V1:
> * fix build error
>
> include/asm-generic/pgtable.h | 17 +++++++++++++++++
> mm/migrate.c | 8 +++++---
> mm/pgtable-generic.c | 14 --------------
> 3 files changed, 22 insertions(+), 17 deletions(-)
>
> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
> index c370b261c720..9401f4819891 100644
> --- a/include/asm-generic/pgtable.h
> +++ b/include/asm-generic/pgtable.h
> @@ -783,6 +783,23 @@ static inline int pmd_clear_huge(pmd_t *pmd)
> }
> #endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */
>
> +#ifndef __HAVE_ARCH_FLUSH_PMD_TLB_RANGE
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +/*
> + * ARCHes with special requirements for evicting THP backing TLB entries can
> + * implement this. Otherwise also, it can help optimize normal TLB flush in
> + * THP regime. stock flush_tlb_range() typically has optimization to nuke the
> + * entire TLB TLB if flush span is greater than a threshold, which will
> + * likely be true for a single huge page. Thus a single thp flush will
> + * invalidate the entire TLB which is not desitable.
> + * e.g. see arch/arc: flush_pmd_tlb_range
> + */
> +#define flush_pmd_tlb_range(vma, addr, end) flush_tlb_range(vma, addr, end)
> +#else
> +#define flush_pmd_tlb_range(vma, addr, end) BUILD_BUG()
> +#endif
> +#endif
> +
> #endif /* !__ASSEMBLY__ */
>
> #ifndef io_remap_pfn_range
> diff --git a/mm/migrate.c b/mm/migrate.c
> index b1034f9c77e7..c079c115d038 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -1767,7 +1767,10 @@ int migrate_misplaced_transhuge_page(struct mm_struct *mm,
> put_page(new_page);
> goto out_fail;
> }
> -
> + /*
> + * We are not sure a pending tlb flush here is for a huge page
> + * mapping or not. Hence use the tlb range variant
> + */
> if (mm_tlb_flush_pending(mm))
> flush_tlb_range(vma, mmun_start, mmun_end);
>
I was thinking we should be able to switch this flush_pmd_tlb_range. But
Kirill was not sure when we discussed this last time. Can we have a
pending tlb flush with PAGE_SIZE page translation, when we are parallely
trying to handle a autonuma fault on that ?
> @@ -1823,12 +1826,11 @@ fail_putback:
> page_add_anon_rmap(new_page, vma, mmun_start, true);
> pmdp_huge_clear_flush_notify(vma, mmun_start, pmd);
> set_pmd_at(mm, mmun_start, pmd, entry);
> - flush_tlb_range(vma, mmun_start, mmun_end);
> update_mmu_cache_pmd(vma, address, &entry);
>
> if (page_count(page) != 2) {
> set_pmd_at(mm, mmun_start, pmd, orig_entry);
> - flush_tlb_range(vma, mmun_start, mmun_end);
> + flush_pmd_tlb_range(vma, mmun_start, mmun_end);
> mmu_notifier_invalidate_range(mm, mmun_start, mmun_end);
> update_mmu_cache_pmd(vma, address, &entry);
> page_remove_rmap(new_page, true);
> diff --git a/mm/pgtable-generic.c b/mm/pgtable-generic.c
> index 9d4767698a1c..3c9c78400300 100644
> --- a/mm/pgtable-generic.c
> +++ b/mm/pgtable-generic.c
> @@ -84,20 +84,6 @@ pte_t ptep_clear_flush(struct vm_area_struct *vma, unsigned long address,
>
> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>
> -#ifndef __HAVE_ARCH_FLUSH_PMD_TLB_RANGE
> -
> -/*
> - * ARCHes with special requirements for evicting THP backing TLB entries can
> - * implement this. Otherwise also, it can help optimize normal TLB flush in
> - * THP regime. stock flush_tlb_range() typically has optimization to nuke the
> - * entire TLB TLB if flush span is greater than a threshhold, which will
> - * likely be true for a single huge page. Thus a single thp flush will
> - * invalidate the entire TLB which is not desitable.
> - * e.g. see arch/arc: flush_pmd_tlb_range
> - */
> -#define flush_pmd_tlb_range(vma, addr, end) flush_tlb_range(vma, addr, end)
> -#endif
> -
> #ifndef __HAVE_ARCH_PMDP_SET_ACCESS_FLAGS
> int pmdp_set_access_flags(struct vm_area_struct *vma,
> unsigned long address, pmd_t *pmdp,
> --
> 2.5.0
-aneesh
next prev parent reply other threads:[~2016-02-10 16:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-10 15:35 [PATCH V2] mm/thp/migration: switch from flush_tlb_range to flush_pmd_tlb_range Aneesh Kumar K.V
2016-02-10 15:35 ` Aneesh Kumar K.V
2016-02-10 16:14 ` Aneesh Kumar K.V [this message]
2016-02-10 16:14 ` Aneesh Kumar K.V
2016-03-17 9:35 ` ARC !THP broken in linux-next (was Re: [PATCH V2] mm/thp/migration: switch from flush_tlb_range to flush_pmd_tlb_range) Vineet Gupta
2016-03-17 9:35 ` Vineet Gupta
2016-03-17 10:05 ` Vineet Gupta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vb5wwnjk.fsf@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=Vineet.Gupta1@synopsys.com \
--cc=akpm@linux-foundation.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.