lkml.org 
[lkml]   [2020]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 5/6] mm: tlb: Provide flush_*_tlb_range wrappers
On Mon, May 25, 2020 at 03:19:42PM +0800, Zhenyu Ye wrote:
> On 2020/5/22 23:42, Catalin Marinas wrote:
> > On Thu, Apr 23, 2020 at 09:56:55PM +0800, Zhenyu Ye wrote:
> >> diff --git a/mm/pgtable-generic.c b/mm/pgtable-generic.c
> >> index 3d7c01e76efc..3eff199d3507 100644
> >> --- a/mm/pgtable-generic.c
> >> +++ b/mm/pgtable-generic.c
> >> @@ -101,6 +101,28 @@ pte_t ptep_clear_flush(struct vm_area_struct *vma, unsigned long address,
> >>
> >> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> >>
> >> +#ifndef __HAVE_ARCH_FLUSH_PMD_TLB_RANGE
> >> +
> >> +#define FLUSH_Pxx_TLB_RANGE(_pxx) \
> >> +void flush_##_pxx##_tlb_range(struct vm_area_struct *vma, \
> >> + unsigned long addr, unsigned long end) \
> >> +{ \
> >> + struct mmu_gather tlb; \
> >> + \
> >> + tlb_gather_mmu(&tlb, vma->vm_mm, addr, end); \
> >> + tlb_start_vma(&tlb, vma); \
> >> + tlb_flush_##_pxx##_range(&tlb, addr, end - addr); \
> >> + tlb_end_vma(&tlb, vma); \
> >> + tlb_finish_mmu(&tlb, addr, end); \
> >> +}
> >
> > I may have confused myself (flush_p??_tlb_* vs. tlb_flush_p??_*) but do
> > actually need this whole tlb_gather thing here? IIUC (by grep'ing),
> > flush_p?d_tlb_range() is only called on huge pages, so we should know
> > the level already.
>
> tlb_flush_##_pxx##_range() is used to set tlb->cleared_*,
> flush_##_pxx##_tlb_range() will actually flush the TLB entry.
>
> In arch64, tlb_flush_p?d_range() is defined as:
>
> #define flush_pmd_tlb_range(vma, addr, end) flush_tlb_range(vma, addr, end)
> #define flush_pud_tlb_range(vma, addr, end) flush_tlb_range(vma, addr, end)

Currently, flush_p??_tlb_range() are generic and defined as above. I
think in the generic code they can remain an alias for
flush_tlb_range().

On arm64, we can redefine them as:

#define flush_pte_tlb_range(vma, addr, end) __flush_tlb_range(vma, addr, end, 3)
#define flush_pmd_tlb_range(vma, addr, end) __flush_tlb_range(vma, addr, end, 2)
#define flush_pud_tlb_range(vma, addr, end) __flush_tlb_range(vma, addr, end, 1)
#define flush_p4d_tlb_range(vma, addr, end) __flush_tlb_range(vma, addr, end, 0)

(unless the compiler optimises away all the mmu_gather stuff in your
macro above but they don't look trivial to me)

Also, I don't see the new flush_pte_* and flush_p4d_* macros used
anywhere and I don't think they are needed. The pte equivalent is
flush_tlb_page() (we need to make sure it's not used on a pmd in the
hugetlb context).

> So even if we know the level here, we can not pass the value to tlbi
> instructions (flush_tlb_range() is a common kernel interface and retro-fit it
> needs lots of changes), according to Peter's suggestion, I finally decide to
> pass the value of TTL by the tlb_gather_* frame.[1]

My comment was about the generic implementation using mmu_gather as you
are proposing. We don't need to change the flush_tlb_range() interface,
nor do we need to rewrite flush_p??_tlb_range().

--
Catalin

\
 
 \ /
  Last update: 2020-05-26 16:53    [W:0.066 / U:1.992 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site