On 10/26/2012 05:12 PM, Alan Cox wrote:

On Fri, 26 Oct 2012 14:45:02 -0400
Rik van Riel [off-list ref] wrote:

quoted

Intel has an architectural guarantee that the TLB entry causing
a page fault gets invalidated automatically. This means
we should be able to drop the local TLB invalidation.

Because of the way other areas of the page fault code work,
chances are good that all x86 CPUs do this.  However, if
someone somewhere has an x86 CPU that does not invalidate
the TLB entry causing a page fault, this one-liner should
be easy to revert.

This does not strike me as a good standard of validation for such a change

At the very least we should have an ACK from AMD and from VIA, and
preferably ping RDC and some of the other embedded folks. Given an AMD
and VIA ACK I'd be fine. I doubt anyone knows any more what Cyrix CPUs
did or cared about and I imagine H Peter or Linus can answer for
Transmeta ;-)

Florian, would you happen to know who at RDC could be contacted
to verify whether a TLB entry causing a page fault gets
invalidated automatically, upon entering the page fault path?

Borislav, would you happen to know whether AMD (and VIA) CPUs
automatically invalidate TLB entries that cause page faults?
If you do not know, would you happen who to ask? :)

If these CPUs do not invalidate a TLB entry causing a page
fault (a write fault on a read-only PTE), then we may have to
change the kernel so flush_tlb_fix_spurious_fault does
something on the CPU models in question...

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>