Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757928Ab2F0XXy (ORCPT ); Wed, 27 Jun 2012 19:23:54 -0400 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 X-Google-Sender-Auth: Sabp52cv_BE9y3Ry7IEDZYW17Jk Message-ID: Subject: Re: [PATCH 08/20] mm: Optimize fullmm TLB flushing 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 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 Content-Length: 1399 Lines: 32 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 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/