Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758515Ab2J0Niw (ORCPT ); Sat, 27 Oct 2012 09:38:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21241 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758245Ab2J0Niu (ORCPT ); Sat, 27 Oct 2012 09:38:50 -0400 Message-ID: <508BE459.2080406@redhat.com> Date: Sat, 27 Oct 2012 09:40:41 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121009 Thunderbird/16.0 MIME-Version: 1.0 To: Alan Cox CC: Ingo Molnar , Andi Kleen , Michel Lespinasse , Linus Torvalds , Peter Zijlstra , Andrea Arcangeli , Mel Gorman , Johannes Weiner , Thomas Gleixner , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, florian@openwrt.org, Borislav Petkov Subject: Re: [PATCH 2/3] x86,mm: drop TLB flush from ptep_set_access_flags References: <20121025121617.617683848@chello.nl> <20121025124832.840241082@chello.nl> <5089F5B5.1050206@redhat.com> <508A0A0D.4090001@redhat.com> <508A8D31.9000106@redhat.com> <20121026132601.GC9886@gmail.com> <20121026144502.6e94643e@dull> <20121026221254.7d32c8bf@pyramind.ukuu.org.uk> In-Reply-To: <20121026221254.7d32c8bf@pyramind.ukuu.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1775 Lines: 39 On 10/26/2012 05:12 PM, Alan Cox wrote: > On Fri, 26 Oct 2012 14:45:02 -0400 > Rik van Riel 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 ;-) 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/