From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751555Ab2J0K3u (ORCPT ); Sat, 27 Oct 2012 06:29:50 -0400 Received: from mail-ea0-f174.google.com ([209.85.215.174]:63497 "EHLO mail-ea0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751106Ab2J0K3r (ORCPT ); Sat, 27 Oct 2012 06:29:47 -0400 Date: Sat, 27 Oct 2012 12:29:42 +0200 From: Ingo Molnar To: Rik van Riel Cc: Alan Cox , 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: <20121027102941.GA27049@gmail.com> References: <508A0A0D.4090001@redhat.com> <508A8D31.9000106@redhat.com> <20121026132601.GC9886@gmail.com> <20121026144502.6e94643e@dull> <20121026221254.7d32c8bf@pyramind.ukuu.org.uk> <508B59B0.5010503@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <508B59B0.5010503@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Rik van Riel wrote: > 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 ;-) > > Fair enough. > > If it turns out any of those CPUs need an explicit flush, then > we can also adjust flush_tlb_fix_spurious_fault to actually do > a local flush on x86 (or at least on those CPUs). Yes. And even if we have 'confirmation' from documentation and elsewhere, testing has to be done to see actual real behavior of CPUs, so this is going to be a separate, bisectable commit put under surveillance ;-) Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx124.postini.com [74.125.245.124]) by kanga.kvack.org (Postfix) with SMTP id 4B1BB6B0072 for ; Sat, 27 Oct 2012 06:29:48 -0400 (EDT) Received: by mail-ee0-f41.google.com with SMTP id c4so1727946eek.14 for ; Sat, 27 Oct 2012 03:29:46 -0700 (PDT) Date: Sat, 27 Oct 2012 12:29:42 +0200 From: Ingo Molnar Subject: Re: [PATCH 2/3] x86,mm: drop TLB flush from ptep_set_access_flags Message-ID: <20121027102941.GA27049@gmail.com> References: <508A0A0D.4090001@redhat.com> <508A8D31.9000106@redhat.com> <20121026132601.GC9886@gmail.com> <20121026144502.6e94643e@dull> <20121026221254.7d32c8bf@pyramind.ukuu.org.uk> <508B59B0.5010503@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <508B59B0.5010503@redhat.com> Sender: owner-linux-mm@kvack.org List-ID: To: Rik van Riel Cc: Alan Cox , 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 * Rik van Riel wrote: > 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 ;-) > > Fair enough. > > If it turns out any of those CPUs need an explicit flush, then > we can also adjust flush_tlb_fix_spurious_fault to actually do > a local flush on x86 (or at least on those CPUs). Yes. And even if we have 'confirmation' from documentation and elsewhere, testing has to be done to see actual real behavior of CPUs, so this is going to be a separate, bisectable commit put under surveillance ;-) Thanks, Ingo -- 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: email@kvack.org