From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965683Ab2JZSDX (ORCPT ); Fri, 26 Oct 2012 14:03:23 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:48484 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964973Ab2JZSDW (ORCPT ); Fri, 26 Oct 2012 14:03:22 -0400 MIME-Version: 1.0 In-Reply-To: <508ACE6E.8060303@redhat.com> References: <20121025121617.617683848@chello.nl> <20121025124832.840241082@chello.nl> <5089F5B5.1050206@redhat.com> <508A0A0D.4090001@redhat.com> <508ACE6E.8060303@redhat.com> From: Linus Torvalds Date: Fri, 26 Oct 2012 11:02:59 -0700 X-Google-Sender-Auth: YEMuxWt0H2n2k0FpDYLWSbMbV7g Message-ID: Subject: Re: [PATCH 05/31] x86/mm: Reduce tlb flushes from ptep_set_access_flags() To: Rik van Riel Cc: Michel Lespinasse , Peter Zijlstra , Andrea Arcangeli , Mel Gorman , Johannes Weiner , Thomas Gleixner , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Ingo Molnar Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 26, 2012 at 10:54 AM, Rik van Riel wrote: > > Would tlb_fix_spurious_fault take care of that on those > architectures? .. assuming that they implement it as a real TLB flush, yes. But maybe the architecture never noticed that it happened to depend on the fact that we do a cross-CPU invalidate? So a missing tlb_fix_spurious_fault() implementation could cause a short loop of repeated page faults, until the IPI happens. And it would be so incredibly rare that nobody would ever have noticed. And if that could have happened, then with the cross-cpu invalidate removed, the "incredibly rare short-lived constant page fault retry" could turn into "incredibly rare lockup due to infinite page fault retry due to TLB entry that never turns dirty despite it being marked dirty by SW in the in-memory page tables". Very unlikely, I agree. And this is only relevant for the non-x86 case, so changing the x86-specific optimized version is an independent issue. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx145.postini.com [74.125.245.145]) by kanga.kvack.org (Postfix) with SMTP id 68EB96B0073 for ; Fri, 26 Oct 2012 14:03:22 -0400 (EDT) Received: by mail-wg0-f45.google.com with SMTP id dq12so1987161wgb.26 for ; Fri, 26 Oct 2012 11:03:20 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <508ACE6E.8060303@redhat.com> References: <20121025121617.617683848@chello.nl> <20121025124832.840241082@chello.nl> <5089F5B5.1050206@redhat.com> <508A0A0D.4090001@redhat.com> <508ACE6E.8060303@redhat.com> From: Linus Torvalds Date: Fri, 26 Oct 2012 11:02:59 -0700 Message-ID: Subject: Re: [PATCH 05/31] x86/mm: Reduce tlb flushes from ptep_set_access_flags() Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Rik van Riel Cc: Michel Lespinasse , Peter Zijlstra , Andrea Arcangeli , Mel Gorman , Johannes Weiner , Thomas Gleixner , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Ingo Molnar On Fri, Oct 26, 2012 at 10:54 AM, Rik van Riel wrote: > > Would tlb_fix_spurious_fault take care of that on those > architectures? .. assuming that they implement it as a real TLB flush, yes. But maybe the architecture never noticed that it happened to depend on the fact that we do a cross-CPU invalidate? So a missing tlb_fix_spurious_fault() implementation could cause a short loop of repeated page faults, until the IPI happens. And it would be so incredibly rare that nobody would ever have noticed. And if that could have happened, then with the cross-cpu invalidate removed, the "incredibly rare short-lived constant page fault retry" could turn into "incredibly rare lockup due to infinite page fault retry due to TLB entry that never turns dirty despite it being marked dirty by SW in the in-memory page tables". Very unlikely, I agree. And this is only relevant for the non-x86 case, so changing the x86-specific optimized version is an independent issue. Linus -- 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