linux-kernel - Re: [PATCH V2] mm/thp/migration: switch from flush_tlb_range to flush_pmd_tlb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 10 Feb 2016 21:44:07 +0530
From:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	akpm@...ux-foundation.org,
	Mel Gorman <mgorman@...hsingularity.net>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Vineet Gupta <Vineet.Gupta1@...opsys.com>
Cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2] mm/thp/migration: switch from flush_tlb_range to flush_pmd_tlb_range

"Aneesh Kumar K.V" <aneesh.kumar@...ux.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@...ux.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