Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758768Ab2JZNOW (ORCPT ); Fri, 26 Oct 2012 09:14:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24786 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750980Ab2JZNOU (ORCPT ); Fri, 26 Oct 2012 09:14:20 -0400 Message-ID: <508A8D31.9000106@redhat.com> Date: Fri, 26 Oct 2012 09:16:33 -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: Andi Kleen CC: 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, Ingo Molnar Subject: Re: [PATCH 05/31] x86/mm: Reduce tlb flushes from ptep_set_access_flags() References: <20121025121617.617683848@chello.nl> <20121025124832.840241082@chello.nl> <5089F5B5.1050206@redhat.com> <508A0A0D.4090001@redhat.com> In-Reply-To: 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: 1611 Lines: 39 On 10/26/2012 08:48 AM, Andi Kleen wrote: > Michel Lespinasse writes: > >> On Thu, Oct 25, 2012 at 9:23 PM, Linus Torvalds >> wrote: >>> On Thu, Oct 25, 2012 at 8:57 PM, Rik van Riel wrote: >>>> >>>> That may not even be needed. Apparently Intel chips >>>> automatically flush an entry from the TLB when it >>>> causes a page fault. I assume AMD chips do the same, >>>> because flush_tlb_fix_spurious_fault evaluates to >>>> nothing on x86. >>> >>> Yes. It's not architected as far as I know, though. But I agree, it's >>> possible - even likely - we could avoid TLB flushing entirely on x86. >> >> Actually, it is architected on x86. This was first described in the >> intel appnote 317080 "TLBs, Paging-Structure Caches, and Their >> Invalidation", last paragraph of section 5.1. Nowadays, the same >> contents are buried somewhere in Volume 3 of the architecture manual >> (in my copy: 4.10.4.1 Operations that Invalidate TLBs and >> Paging-Structure Caches) > > This unfortunately would only work for processes with no threads > because it only works on the current logical CPU. That is fine. Potentially triggering a spurious page fault on another CPU is bound to be better than always doing a synchronous remote TLB flush, waiting for who knows how many CPUs to acknowledge the IPI... -- 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/