From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936996AbdDSPQ7 convert rfc822-to-8bit (ORCPT ); Wed, 19 Apr 2017 11:16:59 -0400 Received: from smtp-out4.electric.net ([192.162.216.194]:53010 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934922AbdDSPQz (ORCPT ); Wed, 19 Apr 2017 11:16:55 -0400 From: David Laight To: "'Christophe Leroy'" , Benjamin Herrenschmidt , Paul Mackerras , "Michael Ellerman" , Scott Wood CC: "linuxppc-dev@lists.ozlabs.org" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH] powerpc/32: Move entry_32 functions just after HEAD functions. Thread-Topic: [PATCH] powerpc/32: Move entry_32 functions just after HEAD functions. Thread-Index: AQHSuBHDDDIh7W69dE2M20Ls7aPDIqHMz0zQ Date: Wed, 19 Apr 2017 15:16:33 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DCFFD56A5@AcuExch.aculab.com> References: <20170418070126.A18EF67952@localhost.localdomain> In-Reply-To: <20170418070126.A18EF67952@localhost.localdomain> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuExch.aculab.com X-TLS: TLSv1:AES128-SHA:128 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Christophe Leroy > By default, PPC8xx PINs an ITLB on the first 8M of memory in order > to avoid any ITLB miss on kernel code. > However, with some debug functions like DEBUG_PAGEALLOC and > (soon to come) DEBUG_RODATA, the PINned TLB is invalidated soon > after startup so ITLB missed start to happen also on the kernel code. > > In order to avoid any ITLB miss in a critical section, we have to > ensure that their is no page boundary crossed between the setup of > a new value in SRR0/SRR1 and the associated RFI. This cannot be done > easily if entry_32 functions sits in the middle of other .text > functions. By placing entry_32 just after the .head section (as already > done for entry_64 on PPC64), we can more easily ensure the issue > doesn't happen. Shouldn't this be done by putting all the functions that 'matter' into a named section instead of relying on the order of the input files? (Which is what I think this is doing.) David