From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx114.postini.com [74.125.245.114]) by kanga.kvack.org (Postfix) with SMTP id 2B1506B0088 for ; Wed, 27 Jun 2012 18:23:53 -0400 (EDT) Received: by wibhq4 with SMTP id hq4so1354240wib.8 for ; Wed, 27 Jun 2012 15:23:51 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20120627212830.693232452@chello.nl> References: <20120627211540.459910855@chello.nl> <20120627212830.693232452@chello.nl> From: Linus Torvalds Date: Wed, 27 Jun 2012 15:23:28 -0700 Message-ID: Subject: Re: [PATCH 02/20] mm: Add optional TLB flush to generic RCU page-table freeing Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.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 , Hans-Christian Egtvedt , Ralf Baechle , Kyle McMartin , James Bottomley , Chris Zankel On Wed, Jun 27, 2012 at 2:15 PM, Peter Zijlstra wrote: > > Certain architectures (viz. x86, arm, s390) have hardware page-table > walkers (#PF). So during the RCU page-table teardown process make sure > we do a tlb flush of page-table pages on all relevant CPUs to > synchronize against hardware walkers, and then free the pages. NACK. Why would hw page table walkers be that special? Plus your config option is horribly done anyway, where you do it as some kind of "default y" and then have complex conditionals on it. Plus it really isn't about hardware page table walkers at all. It's more about the possibility of speculative TLB fils, it has nothing to do with *how* they are done. Sure, it's likely that a software pagetable walker wouldn't be something that gets called speculatively, but it's not out of the question. So I think your config option is totally mis-designed and actively misleading. It's also horrible from a design standpoint, since it's entirely possible that some day POWERPC will actually see the light and do speculative TLB fills etc. So *if* this needs to be done, it needs to be done right. That means: - don't talk about HW walking, since it's not about that - don't say "if you have speculative walkers", and use an ifndef. Say "If you can *guarantee* that nothing else walks page tables speculatively, and we have only one thread that owns the mmu, and that one thread is us, *then* we can do this optimization". So switch the config option around. - make it a per-architecture thing to say "I guarantee that I never fill the TLB speculatively". Don't do that "default y" with complex conditionals crap. IOW, if Sparc/PPC really want to guarantee that they never fill TLB entries speculatively, and that if we are in a kernel thread they will *never* fill the TLB with anything else, then make them enable CONFIG_STRICT_TLB_FILL or something in their architecture Kconfig files. Not like this patch. And not with the misleading names and comments. 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