Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966556Ab2JZVIf (ORCPT ); Fri, 26 Oct 2012 17:08:35 -0400 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:55875 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966503Ab2JZVId (ORCPT ); Fri, 26 Oct 2012 17:08:33 -0400 Date: Fri, 26 Oct 2012 22:12:54 +0100 From: Alan Cox To: Rik van Riel 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 Subject: Re: [PATCH 2/3] x86,mm: drop TLB flush from ptep_set_access_flags Message-ID: <20121026221254.7d32c8bf@pyramind.ukuu.org.uk> In-Reply-To: <20121026144502.6e94643e@dull> 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> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWysKsSBQMIAwIZCwj///8wIhxoRDXH9QHCAAABeUlEQVQ4jaXTvW7DIBAAYCQTzz2hdq+rdg494ZmBeE5KYHZjm/d/hJ6NfzBJpp5kRb5PHJwvMPMk2L9As5Y9AmYRBL+HAyJKeOU5aHRhsAAvORQ+UEgAvgddj/lwAXndw2laEDqA4x6KEBhjYRCg9tBFCOuJFxg2OKegbWjbsRTk8PPhKPD7HcRxB7cqhgBRp9Dcqs+B8v4CQvFdqeot3Kov6hBUn0AJitrzY+sgUuiA8i0r7+B3AfqKcN6t8M6HtqQ+AOoELCikgQSbgabKaJW3kn5lBs47JSGDhhLKDUh1UMipwwinMYPTBuIBjEclSaGZUk9hDlTb5sUTYN2SFFQuPe4Gox1X0FZOufjgBiV1Vls7b+GvK3SU4wfmcGo9rPPQzgIabfj4TYQo15k3bTHX9RIw/kniir5YbtJF4jkFG+dsDK1IgE413zAthU/vR2HVMmFUPIHTvF6jWCpFaGw/A3qWgnbxpSm9MSmY5b3pM1gvNc/gQfwBsGwF0VCtxZgAAAAASUVORK5CYII= Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1137 Lines: 29 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 ;-) Alan -- 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/