Re: [PATCH 05/31] x86/mm: Reduce tlb flushes from ptep_set_access_flags()

[Rik van Riel]

On 10/26/2012 08:48 AM, Andi Kleen wrote:
> Michel Lespinasse <walken@xxxxxxxxxx> writes:
>
> > On Thu, Oct 25, 2012 at 9:23 PM, Linus Torvalds
> > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> > > On Thu, Oct 25, 2012 at 8:57 PM, Rik van Riel <riel@xxxxxxxxxx> wrote:
> > > > That may not even be needed.  Apparently Intel chips
> > > > automatically flush an entry from the TLB when it
> > > > causes a page fault.  I assume AMD chips do the same,
> > > > because flush_tlb_fix_spurious_fault evaluates to
> > > > nothing on x86.
> > >
> > > Yes. It's not architected as far as I know, though. But I agree, it's
> > > possible - even likely - we could avoid TLB flushing entirely on x86.
> >
> > Actually, it is architected on x86. This was first described in the
> > intel appnote 317080 "TLBs, Paging-Structure Caches, and Their
> > Invalidation", last paragraph of section 5.1. Nowadays, the same
> > contents are buried somewhere in Volume 3 of the architecture manual
> > (in my copy: 4.10.4.1 Operations that Invalidate TLBs and
> > Paging-Structure Caches)
>
> This unfortunately would only work for processes with no threads
> because it only works on the current logical CPU.

That is fine.

Potentially triggering a spurious page fault on
another CPU is bound to be better than always
doing a synchronous remote TLB flush, waiting
for who knows how many CPUs to acknowledge the
IPI...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/