From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [PATCH 08/20] mm: Optimize fullmm TLB flushing Date: Wed, 27 Jun 2012 16:23:30 -0700 Message-ID: References: <20120627211540.459910855@chello.nl> <20120627212831.137126018@chello.nl> <1340838154.10063.86.camel@twins> <1340838807.10063.90.camel@twins> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: In-Reply-To: <1340838807.10063.90.camel@twins> Sender: owner-linux-mm@kvack.org To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, Thomas Gleixner , Ingo Molnar , akpm@linux-foundation.org, Rik van Riel , Hugh Dickins , Mel Gorman , Nick Piggin , Alex Shi , "Nikunj A. Dadhania" , Konrad Rzeszutek Wilk , Benjamin Herrenschmidt , David Miller , Russell King , Catalin Marinas , Chris Metcalf , Martin Schwidefsky , Tony Luck , Paul Mundt , Jeff Dike , Richard Weinberger , Ralf Baechle , Kyle McMartin List-Id: linux-arch.vger.kernel.org On Wed, Jun 27, 2012 at 4:13 PM, Peter Zijlstra wrote: > > That triggered.. is this a problem though, at this point userspace is > very dead so it shouldn't matter, right? It still matters. Even if user space is dead, kernel space accesses can result in TLB fills in user space. Exactly because of things like speculative fills etc. So what can happen - for example - is that the kernel does a indirect jump, and the CPU predicts the destination of the jump that using the branch prediction tables. But the branch prediction tables are obviously just predictions, and they easily contain user addresses etc in them. So the kernel may well end up speculatively doing a TLB fill on a user access. And your whole optimization depends on this not happening, unless I read the logic wrong. The whole "invalidate the TLB just once up-front" approach is *only* valid if you know that nothing is going to ever fill that TLB again. But see above - if we're still running within that TLB context, we have no idea what speculative execution may or may not end up filling. That said, maybe I misread your patch? 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f44.google.com ([74.125.82.44]:43103 "EHLO mail-wg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751910Ab2F0XXw (ORCPT ); Wed, 27 Jun 2012 19:23:52 -0400 MIME-Version: 1.0 In-Reply-To: <1340838807.10063.90.camel@twins> References: <20120627211540.459910855@chello.nl> <20120627212831.137126018@chello.nl> <1340838154.10063.86.camel@twins> <1340838807.10063.90.camel@twins> From: Linus Torvalds Date: Wed, 27 Jun 2012 16:23:30 -0700 Message-ID: Subject: Re: [PATCH 08/20] mm: Optimize fullmm TLB flushing Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-arch-owner@vger.kernel.org List-ID: To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, Thomas Gleixner , Ingo Molnar , akpm@linux-foundation.org, Rik van Riel , Hugh Dickins , Mel Gorman , Nick Piggin , Alex Shi , "Nikunj A. Dadhania" , Konrad Rzeszutek Wilk , Benjamin Herrenschmidt , David Miller , Russell King , Catalin Marinas , Chris Metcalf , Martin Schwidefsky , Tony Luck , Paul Mundt , Jeff Dike , Richard Weinberger , Ralf Baechle , Kyle McMartin , James Bottomley , Chris Zankel Message-ID: <20120627232330.4lfivaQTZIlvpJh4U2bYEN8Y2wHo-MykEwQFRkrDskY@z> On Wed, Jun 27, 2012 at 4:13 PM, Peter Zijlstra wrote: > > That triggered.. is this a problem though, at this point userspace is > very dead so it shouldn't matter, right? It still matters. Even if user space is dead, kernel space accesses can result in TLB fills in user space. Exactly because of things like speculative fills etc. So what can happen - for example - is that the kernel does a indirect jump, and the CPU predicts the destination of the jump that using the branch prediction tables. But the branch prediction tables are obviously just predictions, and they easily contain user addresses etc in them. So the kernel may well end up speculatively doing a TLB fill on a user access. And your whole optimization depends on this not happening, unless I read the logic wrong. The whole "invalidate the TLB just once up-front" approach is *only* valid if you know that nothing is going to ever fill that TLB again. But see above - if we're still running within that TLB context, we have no idea what speculative execution may or may not end up filling. That said, maybe I misread your patch? Linus