Messages in this thread | | | From | Catalin Marinas <> | Date | Wed, 22 Jul 2015 23:48:42 +0100 | Subject | Re: [PATCH] mm: Flush the TLB for a single address in a huge page |
| |
On 22 July 2015 at 22:39, David Rientjes <rientjes@google.com> wrote: > On Wed, 22 Jul 2015, Catalin Marinas wrote: > >> When the page table entry is a huge page (and not a table), there is no >> need to flush the TLB by range. This patch changes flush_tlb_range() to >> flush_tlb_page() in functions where we know the pmd entry is a huge >> page. >> >> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> >> Cc: Andrew Morton <akpm@linux-foundation.org> >> Cc: Andrea Arcangeli <aarcange@redhat.com> >> --- >> >> Hi, >> >> That's just a minor improvement but it saves iterating over each small >> page in a huge page when a single TLB entry is used (we already have a >> similar assumption in __tlb_adjust_range). > > For x86 smp, this seems to mean the difference between unconditional > flush_tlb_page() and local_flush_tlb() due to > tlb_single_page_flush_ceiling, so I don't think this just removes the > iteration.
You are right, on x86 the tlb_single_page_flush_ceiling seems to be 33, so for an HPAGE_SIZE range the code does a local_flush_tlb() always. I would say a single page TLB flush is more efficient than a whole TLB flush but I'm not familiar enough with x86.
Alternatively, I could introduce a flush_tlb_pmd_huge_page (suggested by Andrea separately) and let the architectures deal with this as they see fit. The default definition would do a flush_tlb_range(vma, address, address + HPAGE_SIZE). For arm64, I'll define it as flush_tlb_page(vma, address).
-- Catalin
| |