Re: [RFC 15/20] mm: detect deferred TLB flushes in vma granularity

> On Feb 2, 2021, at 12:52 PM, Nadav Amit wrote: > >  >> >>> On Feb 1, 2021, at 4:14 PM, Andy Lutomirski wrote: >>> >>> On Feb 1, 2021, at 2:04 PM, Nadav Amit wrote: >>> >>> Andy’s comments managed to make me realize this code is wrong. We must >>> call inc_mm_tlb_gen(mm) every tim

Re: [RFC 15/20] mm: detect deferred TLB flushes in vma granularity

> On Feb 1, 2021, at 4:14 PM, Andy Lutomirski wrote: > > >> On Feb 1, 2021, at 2:04 PM, Nadav Amit wrote: >> >> Andy’s comments managed to make me realize this code is wrong. We must >> call inc_mm_tlb_gen(mm) every time. >> >> Otherwise, a CPU that saw the old tlb_gen and updated it in its l

Re: [RFC 15/20] mm: detect deferred TLB flushes in vma granularity

> On Feb 1, 2021, at 2:04 PM, Nadav Amit wrote: > >  >> >> On Jan 30, 2021, at 4:11 PM, Nadav Amit wrote: >> >> From: Nadav Amit >> >> Currently, deferred TLB flushes are detected in the mm granularity: if >> there is any deferred TLB flush in the entire address space due to NUMA >> migra

Re: [RFC 15/20] mm: detect deferred TLB flushes in vma granularity

> On Jan 30, 2021, at 4:11 PM, Nadav Amit wrote: > > From: Nadav Amit > > Currently, deferred TLB flushes are detected in the mm granularity: if > there is any deferred TLB flush in the entire address space due to NUMA > migration, pte_accessible() in x86 would return true, and > ptep_clear_flu