On Thu, Jul 23, 2015 at 03:13:03PM +0100, Andrea Arcangeli wrote: > On Thu, Jul 23, 2015 at 11:49:38AM +0100, Catalin Marinas wrote: > > On Thu, Jul 23, 2015 at 12:05:21AM +0100, Dave Hansen wrote: > > > On 07/22/2015 03:48 PM, Catalin Marinas wrote: > > > > 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. > > > > > > The last time I looked, the instruction to invalidate a single page is > > > more expensive than the instruction to flush the entire TLB. [...] > > Another question is whether flushing a single address is enough for a > > huge page. I assumed it is since tlb_remove_pmd_tlb_entry() only adjusts [...] > > the mmu_gather range by PAGE_SIZE (rather than HPAGE_SIZE) and > > no-one complained so far. AFAICT, there are only 3 architectures > > that don't use asm-generic/tlb.h but they all seem to handle this > > case: > > Agreed that archs using the generic tlb.h that sets the tlb->end to > address+PAGE_SIZE should be fine with the flush_tlb_page. > > > arch/arm: it implements tlb_remove_pmd_tlb_entry() in a similar way to > > the generic one > > > > arch/s390: tlb_remove_pmd_tlb_entry() is a no-op > > I guess s390 is fine too but I'm not convinced that the fact it won't > adjust the tlb->start/end is a guarantees that flush_tlb_page is > enough when a single 2MB TLB has to be invalidated (not during range > zapping). > > For the range zapping, could the arch decide to unconditionally flush > the whole TLB without doing the tlb->start/end tracking by overriding > tlb_gather_mmu in a way that won't call __tlb_reset_range? There seems > to be quite some flexibility in the per-arch tlb_gather_mmu setup in > order to unconditionally set tlb->start/end to the total range zapped, > without actually narrowing it down during the pagetable walk.
You are right, looking at the s390 code, tlb_finish_mmu() flushes the whole TLB, so the ranges don't seem to matter. I'm cc'ing the s390 maintainers to confirm whether this patch affects them in any way: https://lkml.org/lkml/2015/7/22/521 IIUC, all the functions touched by this patch are implemented by s390 in its specific way, so I don't think it makes any difference: pmdp_set_access_flags pmdp_clear_flush_young pmdp_huge_clear_flush pmdp_splitting_flush pmdp_invalidate -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
