[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121026221254.7d32c8bf@pyramind.ukuu.org.uk>
Date: Fri, 26 Oct 2012 22:12:54 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Rik van Riel <riel@...hat.com>
Cc: Ingo Molnar <mingo@...nel.org>, Andi Kleen <andi@...stfloor.org>,
Michel Lespinasse <walken@...gle.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Andrea Arcangeli <aarcange@...hat.com>,
Mel Gorman <mgorman@...e.de>,
Johannes Weiner <hannes@...xchg.org>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 2/3] x86,mm: drop TLB flush from ptep_set_access_flags
On Fri, 26 Oct 2012 14:45:02 -0400
Rik van Riel <riel@...hat.com> wrote:
> 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 ;-)
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists