From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 28866C4167B for ; Wed, 2 Mar 2022 03:22:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239313AbiCBDXK (ORCPT ); Tue, 1 Mar 2022 22:23:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44780 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239271AbiCBDXJ (ORCPT ); Tue, 1 Mar 2022 22:23:09 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 2738B272A; Tue, 1 Mar 2022 19:22:26 -0800 (PST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D55FF11FB; Tue, 1 Mar 2022 19:22:25 -0800 (PST) Received: from [10.163.49.202] (unknown [10.163.49.202]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 000B23F73D; Tue, 1 Mar 2022 19:22:16 -0800 (PST) Subject: Re: [PATCH V3 09/30] arm/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT To: Christophe Leroy , "Russell King (Oracle)" Cc: "linux-ia64@vger.kernel.org" , "linux-sh@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-mm@kvack.org" , "sparclinux@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "linux-arch@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-hexagon@vger.kernel.org" , "linux-csky@vger.kernel.org" , Christoph Hellwig , "geert@linux-m68k.org" , "linux-snps-arc@lists.infradead.org" , "linux-xtensa@linux-xtensa.org" , Arnd Bergmann , "linux-um@lists.infradead.org" , "linux-m68k@lists.linux-m68k.org" , "openrisc@lists.librecores.org" , "linux-arm-kernel@lists.infradead.org" , "linux-parisc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-alpha@vger.kernel.org" , "akpm@linux-foundation.org" , "linuxppc-dev@lists.ozlabs.org" References: <1646045273-9343-1-git-send-email-anshuman.khandual@arm.com> <1646045273-9343-10-git-send-email-anshuman.khandual@arm.com> <542fa048-131e-240b-cc3a-fd4fff7ce4ba@arm.com> From: Anshuman Khandual Message-ID: Date: Wed, 2 Mar 2022 08:52:14 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-sh@vger.kernel.org On 3/1/22 1:46 PM, Christophe Leroy wrote: > > > Le 01/03/2022 à 01:31, Russell King (Oracle) a écrit : >> On Tue, Mar 01, 2022 at 05:30:41AM +0530, Anshuman Khandual wrote: >>> On 2/28/22 4:27 PM, Russell King (Oracle) wrote: >>>> On Mon, Feb 28, 2022 at 04:17:32PM +0530, Anshuman Khandual wrote: >>>>> This defines and exports a platform specific custom vm_get_page_prot() via >>>>> subscribing ARCH_HAS_VM_GET_PAGE_PROT. Subsequently all __SXXX and __PXXX >>>>> macros can be dropped which are no longer needed. >>>> >>>> What I would really like to know is why having to run _code_ to work out >>>> what the page protections need to be is better than looking it up in a >>>> table. >>>> >>>> Not only is this more expensive in terms of CPU cycles, it also brings >>>> additional code size with it. >>>> >>>> I'm struggling to see what the benefit is. >>> >>> Currently vm_get_page_prot() is also being _run_ to fetch required page >>> protection values. Although that is being run in the core MM and from a >>> platform perspective __SXXX, __PXXX are just being exported for a table. >>> Looking it up in a table (and applying more constructs there after) is >>> not much different than a clean switch case statement in terms of CPU >>> usage. So this is not more expensive in terms of CPU cycles. >> >> I disagree. > > So do I. > >> >> However, let's base this disagreement on some evidence. Here is the >> present 32-bit ARM implementation: >> >> 00000048 : >> 48: e200000f and r0, r0, #15 >> 4c: e3003000 movw r3, #0 >> 4c: R_ARM_MOVW_ABS_NC .LANCHOR1 >> 50: e3403000 movt r3, #0 >> 50: R_ARM_MOVT_ABS .LANCHOR1 >> 54: e7930100 ldr r0, [r3, r0, lsl #2] >> 58: e12fff1e bx lr >> >> That is five instructions long. > > On ppc32 I get: > > 00000094 : > 94: 3d 20 00 00 lis r9,0 > 96: R_PPC_ADDR16_HA .data..ro_after_init > 98: 54 84 16 ba rlwinm r4,r4,2,26,29 > 9c: 39 29 00 00 addi r9,r9,0 > 9e: R_PPC_ADDR16_LO .data..ro_after_init > a0: 7d 29 20 2e lwzx r9,r9,r4 > a4: 91 23 00 00 stw r9,0(r3) > a8: 4e 80 00 20 blr > > >> >> Please show that your new implementation is not more expensive on >> 32-bit ARM. Please do so by building a 32-bit kernel, and providing >> the disassembly. > > With your series I get: > > 00000000 : > 0: 3d 20 00 00 lis r9,0 > 2: R_PPC_ADDR16_HA .rodata > 4: 39 29 00 00 addi r9,r9,0 > 6: R_PPC_ADDR16_LO .rodata > 8: 54 84 16 ba rlwinm r4,r4,2,26,29 > c: 7d 49 20 2e lwzx r10,r9,r4 > 10: 7d 4a 4a 14 add r10,r10,r9 > 14: 7d 49 03 a6 mtctr r10 > 18: 4e 80 04 20 bctr > 1c: 39 20 03 15 li r9,789 > 20: 91 23 00 00 stw r9,0(r3) > 24: 4e 80 00 20 blr > 28: 39 20 01 15 li r9,277 > 2c: 91 23 00 00 stw r9,0(r3) > 30: 4e 80 00 20 blr > 34: 39 20 07 15 li r9,1813 > 38: 91 23 00 00 stw r9,0(r3) > 3c: 4e 80 00 20 blr > 40: 39 20 05 15 li r9,1301 > 44: 91 23 00 00 stw r9,0(r3) > 48: 4e 80 00 20 blr > 4c: 39 20 01 11 li r9,273 > 50: 4b ff ff d0 b 20 > > > That is definitely more expensive, it implements a table of branches. Okay, will split out the PPC32 implementation that retains existing table look up method. Also planning to keep that inside same file (arch/powerpc/mm/mmap.c), unless you have a difference preference. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 41F91C433F5 for ; Wed, 2 Mar 2022 03:22:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=HhyRiGSFD5z5P4b6o49d8x1IAUm/d2D1VwMmpS12gkI=; b=O6y0Ul46Xg6YUK5pYsXKsZO7Nz QVrc5cAF5kFxvFuDDTO7fEXqFvlWTTT7f3EBGAVIr7YT4yDhnPVH447kBW4FzvQLpvor6I4CBBG/G +B7tCgMK3ApToX8/iix4nNA0FifE9xPPgPz/e9tsKPCmDDVrE+V6mje7hwt55jmnzeTjRlC9Y3mOb mf9Ki1ylNtt/oog12B4BMrJ77d5TTTo2rOlXt45MPfeWQdCTsGqh+IuXUNMUCac5FgsyamiBIzbyL JrDV9jgvQj/EFu6yfcOFiNJAl2WW+EbpCgP8CHSkzwxlipDtuo/2PGR1mm+go848+jNONk0tlYK4G OVWNCIUA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nPFZa-001IAW-3h; Wed, 02 Mar 2022 03:22:42 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nPFZK-001I54-VG; Wed, 02 Mar 2022 03:22:28 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D55FF11FB; Tue, 1 Mar 2022 19:22:25 -0800 (PST) Received: from [10.163.49.202] (unknown [10.163.49.202]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 000B23F73D; Tue, 1 Mar 2022 19:22:16 -0800 (PST) Subject: Re: [PATCH V3 09/30] arm/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT To: Christophe Leroy , "Russell King (Oracle)" Cc: "linux-ia64@vger.kernel.org" , "linux-sh@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-mm@kvack.org" , "sparclinux@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "linux-arch@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-hexagon@vger.kernel.org" , "linux-csky@vger.kernel.org" , Christoph Hellwig , "geert@linux-m68k.org" , "linux-snps-arc@lists.infradead.org" , "linux-xtensa@linux-xtensa.org" , Arnd Bergmann , "linux-um@lists.infradead.org" , "linux-m68k@lists.linux-m68k.org" , "openrisc@lists.librecores.org" , "linux-arm-kernel@lists.infradead.org" , "linux-parisc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-alpha@vger.kernel.org" , "akpm@linux-foundation.org" , "linuxppc-dev@lists.ozlabs.org" References: <1646045273-9343-1-git-send-email-anshuman.khandual@arm.com> <1646045273-9343-10-git-send-email-anshuman.khandual@arm.com> <542fa048-131e-240b-cc3a-fd4fff7ce4ba@arm.com> From: Anshuman Khandual Message-ID: Date: Wed, 2 Mar 2022 08:52:14 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220301_192227_127916_5371CA49 X-CRM114-Status: GOOD ( 19.58 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org CgpPbiAzLzEvMjIgMTo0NiBQTSwgQ2hyaXN0b3BoZSBMZXJveSB3cm90ZToKPiAKPiAKPiBMZSAw MS8wMy8yMDIyIMOgIDAxOjMxLCBSdXNzZWxsIEtpbmcgKE9yYWNsZSkgYSDDqWNyaXTCoDoKPj4g T24gVHVlLCBNYXIgMDEsIDIwMjIgYXQgMDU6MzA6NDFBTSArMDUzMCwgQW5zaHVtYW4gS2hhbmR1 YWwgd3JvdGU6Cj4+PiBPbiAyLzI4LzIyIDQ6MjcgUE0sIFJ1c3NlbGwgS2luZyAoT3JhY2xlKSB3 cm90ZToKPj4+PiBPbiBNb24sIEZlYiAyOCwgMjAyMiBhdCAwNDoxNzozMlBNICswNTMwLCBBbnNo dW1hbiBLaGFuZHVhbCB3cm90ZToKPj4+Pj4gVGhpcyBkZWZpbmVzIGFuZCBleHBvcnRzIGEgcGxh dGZvcm0gc3BlY2lmaWMgY3VzdG9tIHZtX2dldF9wYWdlX3Byb3QoKSB2aWEKPj4+Pj4gc3Vic2Ny aWJpbmcgQVJDSF9IQVNfVk1fR0VUX1BBR0VfUFJPVC4gU3Vic2VxdWVudGx5IGFsbCBfX1NYWFgg YW5kIF9fUFhYWAo+Pj4+PiBtYWNyb3MgY2FuIGJlIGRyb3BwZWQgd2hpY2ggYXJlIG5vIGxvbmdl ciBuZWVkZWQuCj4+Pj4KPj4+PiBXaGF0IEkgd291bGQgcmVhbGx5IGxpa2UgdG8ga25vdyBpcyB3 aHkgaGF2aW5nIHRvIHJ1biBfY29kZV8gdG8gd29yayBvdXQKPj4+PiB3aGF0IHRoZSBwYWdlIHBy b3RlY3Rpb25zIG5lZWQgdG8gYmUgaXMgYmV0dGVyIHRoYW4gbG9va2luZyBpdCB1cCBpbiBhCj4+ Pj4gdGFibGUuCj4+Pj4KPj4+PiBOb3Qgb25seSBpcyB0aGlzIG1vcmUgZXhwZW5zaXZlIGluIHRl cm1zIG9mIENQVSBjeWNsZXMsIGl0IGFsc28gYnJpbmdzCj4+Pj4gYWRkaXRpb25hbCBjb2RlIHNp emUgd2l0aCBpdC4KPj4+Pgo+Pj4+IEknbSBzdHJ1Z2dsaW5nIHRvIHNlZSB3aGF0IHRoZSBiZW5l Zml0IGlzLgo+Pj4KPj4+IEN1cnJlbnRseSB2bV9nZXRfcGFnZV9wcm90KCkgaXMgYWxzbyBiZWlu ZyBfcnVuXyB0byBmZXRjaCByZXF1aXJlZCBwYWdlCj4+PiBwcm90ZWN0aW9uIHZhbHVlcy4gQWx0 aG91Z2ggdGhhdCBpcyBiZWluZyBydW4gaW4gdGhlIGNvcmUgTU0gYW5kIGZyb20gYQo+Pj4gcGxh dGZvcm0gcGVyc3BlY3RpdmUgX19TWFhYLCBfX1BYWFggYXJlIGp1c3QgYmVpbmcgZXhwb3J0ZWQg Zm9yIGEgdGFibGUuCj4+PiBMb29raW5nIGl0IHVwIGluIGEgdGFibGUgKGFuZCBhcHBseWluZyBt b3JlIGNvbnN0cnVjdHMgdGhlcmUgYWZ0ZXIpIGlzCj4+PiBub3QgbXVjaCBkaWZmZXJlbnQgdGhh biBhIGNsZWFuIHN3aXRjaCBjYXNlIHN0YXRlbWVudCBpbiB0ZXJtcyBvZiBDUFUKPj4+IHVzYWdl LiBTbyB0aGlzIGlzIG5vdCBtb3JlIGV4cGVuc2l2ZSBpbiB0ZXJtcyBvZiBDUFUgY3ljbGVzLgo+ Pgo+PiBJIGRpc2FncmVlLgo+IAo+IFNvIGRvIEkuCj4gCj4+Cj4+IEhvd2V2ZXIsIGxldCdzIGJh c2UgdGhpcyBkaXNhZ3JlZW1lbnQgb24gc29tZSBldmlkZW5jZS4gSGVyZSBpcyB0aGUKPj4gcHJl c2VudCAzMi1iaXQgQVJNIGltcGxlbWVudGF0aW9uOgo+Pgo+PiAwMDAwMDA0OCA8dm1fZ2V0X3Bh Z2VfcHJvdD46Cj4+ICAgICAgICA0ODogICAgICAgZTIwMDAwMGYgICAgICAgIGFuZCAgICAgcjAs IHIwLCAjMTUKPj4gICAgICAgIDRjOiAgICAgICBlMzAwMzAwMCAgICAgICAgbW92dyAgICByMywg IzAKPj4gICAgICAgICAgICAgICAgICAgICAgICAgIDRjOiBSX0FSTV9NT1ZXX0FCU19OQyAgIC5M QU5DSE9SMQo+PiAgICAgICAgNTA6ICAgICAgIGUzNDAzMDAwICAgICAgICBtb3Z0ICAgIHIzLCAj MAo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgNTA6IFJfQVJNX01PVlRfQUJTICAgICAgLkxB TkNIT1IxCj4+ICAgICAgICA1NDogICAgICAgZTc5MzAxMDAgICAgICAgIGxkciAgICAgcjAsIFty MywgcjAsIGxzbCAjMl0KPj4gICAgICAgIDU4OiAgICAgICBlMTJmZmYxZSAgICAgICAgYnggICAg ICBscgo+Pgo+PiBUaGF0IGlzIGZpdmUgaW5zdHJ1Y3Rpb25zIGxvbmcuCj4gCj4gT24gcHBjMzIg SSBnZXQ6Cj4gCj4gMDAwMDAwOTQgPHZtX2dldF9wYWdlX3Byb3Q+Ogo+ICAgICAgICA5NDoJM2Qg MjAgMDAgMDAgCWxpcyAgICAgcjksMAo+IAkJCTk2OiBSX1BQQ19BRERSMTZfSEEJLmRhdGEuLnJv X2FmdGVyX2luaXQKPiAgICAgICAgOTg6CTU0IDg0IDE2IGJhIAlybHdpbm0gIHI0LHI0LDIsMjYs MjkKPiAgICAgICAgOWM6CTM5IDI5IDAwIDAwIAlhZGRpICAgIHI5LHI5LDAKPiAJCQk5ZTogUl9Q UENfQUREUjE2X0xPCS5kYXRhLi5yb19hZnRlcl9pbml0Cj4gICAgICAgIGEwOgk3ZCAyOSAyMCAy ZSAJbHd6eCAgICByOSxyOSxyNAo+ICAgICAgICBhNDoJOTEgMjMgMDAgMDAgCXN0dyAgICAgcjks MChyMykKPiAgICAgICAgYTg6CTRlIDgwIDAwIDIwIAlibHIKPiAKPiAKPj4KPj4gUGxlYXNlIHNo b3cgdGhhdCB5b3VyIG5ldyBpbXBsZW1lbnRhdGlvbiBpcyBub3QgbW9yZSBleHBlbnNpdmUgb24K Pj4gMzItYml0IEFSTS4gUGxlYXNlIGRvIHNvIGJ5IGJ1aWxkaW5nIGEgMzItYml0IGtlcm5lbCwg YW5kIHByb3ZpZGluZwo+PiB0aGUgZGlzYXNzZW1ibHkuCj4gCj4gV2l0aCB5b3VyIHNlcmllcyBJ IGdldDoKPiAKPiAwMDAwMDAwMCA8dm1fZ2V0X3BhZ2VfcHJvdD46Cj4gICAgIDA6CTNkIDIwIDAw IDAwIAlsaXMgICAgIHI5LDAKPiAJCQkyOiBSX1BQQ19BRERSMTZfSEEJLnJvZGF0YQo+ICAgICA0 OgkzOSAyOSAwMCAwMCAJYWRkaSAgICByOSxyOSwwCj4gCQkJNjogUl9QUENfQUREUjE2X0xPCS5y b2RhdGEKPiAgICAgODoJNTQgODQgMTYgYmEgCXJsd2lubSAgcjQscjQsMiwyNiwyOQo+ICAgICBj Ogk3ZCA0OSAyMCAyZSAJbHd6eCAgICByMTAscjkscjQKPiAgICAxMDoJN2QgNGEgNGEgMTQgCWFk ZCAgICAgcjEwLHIxMCxyOQo+ICAgIDE0Ogk3ZCA0OSAwMyBhNiAJbXRjdHIgICByMTAKPiAgICAx ODoJNGUgODAgMDQgMjAgCWJjdHIKPiAgICAxYzoJMzkgMjAgMDMgMTUgCWxpICAgICAgcjksNzg5 Cj4gICAgMjA6CTkxIDIzIDAwIDAwIAlzdHcgICAgIHI5LDAocjMpCj4gICAgMjQ6CTRlIDgwIDAw IDIwIAlibHIKPiAgICAyODoJMzkgMjAgMDEgMTUgCWxpICAgICAgcjksMjc3Cj4gICAgMmM6CTkx IDIzIDAwIDAwIAlzdHcgICAgIHI5LDAocjMpCj4gICAgMzA6CTRlIDgwIDAwIDIwIAlibHIKPiAg ICAzNDoJMzkgMjAgMDcgMTUgCWxpICAgICAgcjksMTgxMwo+ICAgIDM4Ogk5MSAyMyAwMCAwMCAJ c3R3ICAgICByOSwwKHIzKQo+ICAgIDNjOgk0ZSA4MCAwMCAyMCAJYmxyCj4gICAgNDA6CTM5IDIw IDA1IDE1IAlsaSAgICAgIHI5LDEzMDEKPiAgICA0NDoJOTEgMjMgMDAgMDAgCXN0dyAgICAgcjks MChyMykKPiAgICA0ODoJNGUgODAgMDAgMjAgCWJscgo+ICAgIDRjOgkzOSAyMCAwMSAxMSAJbGkg ICAgICByOSwyNzMKPiAgICA1MDoJNGIgZmYgZmYgZDAgCWIgICAgICAgMjAgPHZtX2dldF9wYWdl X3Byb3QrMHgyMD4KPiAKPiAKPiBUaGF0IGlzIGRlZmluaXRlbHkgbW9yZSBleHBlbnNpdmUsIGl0 IGltcGxlbWVudHMgYSB0YWJsZSBvZiBicmFuY2hlcy4KCk9rYXksIHdpbGwgc3BsaXQgb3V0IHRo ZSBQUEMzMiBpbXBsZW1lbnRhdGlvbiB0aGF0IHJldGFpbnMgZXhpc3RpbmcKdGFibGUgbG9vayB1 cCBtZXRob2QuIEFsc28gcGxhbm5pbmcgdG8ga2VlcCB0aGF0IGluc2lkZSBzYW1lIGZpbGUKKGFy Y2gvcG93ZXJwYy9tbS9tbWFwLmMpLCB1bmxlc3MgeW91IGhhdmUgYSBkaWZmZXJlbmNlIHByZWZl cmVuY2UuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwps aW51eC1yaXNjdiBtYWlsaW5nIGxpc3QKbGludXgtcmlzY3ZAbGlzdHMuaW5mcmFkZWFkLm9yZwpo dHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LXJpc2N2Cg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3FB3EC433EF for ; Wed, 2 Mar 2022 03:22:55 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4K7fZP0mZZz3c2T for ; Wed, 2 Mar 2022 14:22:53 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=arm.com (client-ip=217.140.110.172; helo=foss.arm.com; envelope-from=anshuman.khandual@arm.com; receiver=) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lists.ozlabs.org (Postfix) with ESMTP id 4K7fYw3BjQz2y7M for ; Wed, 2 Mar 2022 14:22:26 +1100 (AEDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D55FF11FB; Tue, 1 Mar 2022 19:22:25 -0800 (PST) Received: from [10.163.49.202] (unknown [10.163.49.202]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 000B23F73D; Tue, 1 Mar 2022 19:22:16 -0800 (PST) Subject: Re: [PATCH V3 09/30] arm/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT To: Christophe Leroy , "Russell King (Oracle)" References: <1646045273-9343-1-git-send-email-anshuman.khandual@arm.com> <1646045273-9343-10-git-send-email-anshuman.khandual@arm.com> <542fa048-131e-240b-cc3a-fd4fff7ce4ba@arm.com> From: Anshuman Khandual Message-ID: Date: Wed, 2 Mar 2022 08:52:14 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "linux-ia64@vger.kernel.org" , "linux-sh@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "sparclinux@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "linux-arch@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-hexagon@vger.kernel.org" , "linux-csky@vger.kernel.org" , Christoph Hellwig , "geert@linux-m68k.org" , "linux-snps-arc@lists.infradead.org" , "linux-xtensa@linux-xtensa.org" , Arnd Bergmann , "linux-um@lists.infradead.org" , "linux-m68k@lists.linux-m68k.org" , "openrisc@lists.librecores.org" , "linux-arm-kernel@lists.infradead.org" , "linux-parisc@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-alpha@vger.kernel.org" , "akpm@linux-foundation.org" , "linuxppc-dev@lists.ozlabs.org" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On 3/1/22 1:46 PM, Christophe Leroy wrote: > > > Le 01/03/2022 à 01:31, Russell King (Oracle) a écrit : >> On Tue, Mar 01, 2022 at 05:30:41AM +0530, Anshuman Khandual wrote: >>> On 2/28/22 4:27 PM, Russell King (Oracle) wrote: >>>> On Mon, Feb 28, 2022 at 04:17:32PM +0530, Anshuman Khandual wrote: >>>>> This defines and exports a platform specific custom vm_get_page_prot() via >>>>> subscribing ARCH_HAS_VM_GET_PAGE_PROT. Subsequently all __SXXX and __PXXX >>>>> macros can be dropped which are no longer needed. >>>> >>>> What I would really like to know is why having to run _code_ to work out >>>> what the page protections need to be is better than looking it up in a >>>> table. >>>> >>>> Not only is this more expensive in terms of CPU cycles, it also brings >>>> additional code size with it. >>>> >>>> I'm struggling to see what the benefit is. >>> >>> Currently vm_get_page_prot() is also being _run_ to fetch required page >>> protection values. Although that is being run in the core MM and from a >>> platform perspective __SXXX, __PXXX are just being exported for a table. >>> Looking it up in a table (and applying more constructs there after) is >>> not much different than a clean switch case statement in terms of CPU >>> usage. So this is not more expensive in terms of CPU cycles. >> >> I disagree. > > So do I. > >> >> However, let's base this disagreement on some evidence. Here is the >> present 32-bit ARM implementation: >> >> 00000048 : >> 48: e200000f and r0, r0, #15 >> 4c: e3003000 movw r3, #0 >> 4c: R_ARM_MOVW_ABS_NC .LANCHOR1 >> 50: e3403000 movt r3, #0 >> 50: R_ARM_MOVT_ABS .LANCHOR1 >> 54: e7930100 ldr r0, [r3, r0, lsl #2] >> 58: e12fff1e bx lr >> >> That is five instructions long. > > On ppc32 I get: > > 00000094 : > 94: 3d 20 00 00 lis r9,0 > 96: R_PPC_ADDR16_HA .data..ro_after_init > 98: 54 84 16 ba rlwinm r4,r4,2,26,29 > 9c: 39 29 00 00 addi r9,r9,0 > 9e: R_PPC_ADDR16_LO .data..ro_after_init > a0: 7d 29 20 2e lwzx r9,r9,r4 > a4: 91 23 00 00 stw r9,0(r3) > a8: 4e 80 00 20 blr > > >> >> Please show that your new implementation is not more expensive on >> 32-bit ARM. Please do so by building a 32-bit kernel, and providing >> the disassembly. > > With your series I get: > > 00000000 : > 0: 3d 20 00 00 lis r9,0 > 2: R_PPC_ADDR16_HA .rodata > 4: 39 29 00 00 addi r9,r9,0 > 6: R_PPC_ADDR16_LO .rodata > 8: 54 84 16 ba rlwinm r4,r4,2,26,29 > c: 7d 49 20 2e lwzx r10,r9,r4 > 10: 7d 4a 4a 14 add r10,r10,r9 > 14: 7d 49 03 a6 mtctr r10 > 18: 4e 80 04 20 bctr > 1c: 39 20 03 15 li r9,789 > 20: 91 23 00 00 stw r9,0(r3) > 24: 4e 80 00 20 blr > 28: 39 20 01 15 li r9,277 > 2c: 91 23 00 00 stw r9,0(r3) > 30: 4e 80 00 20 blr > 34: 39 20 07 15 li r9,1813 > 38: 91 23 00 00 stw r9,0(r3) > 3c: 4e 80 00 20 blr > 40: 39 20 05 15 li r9,1301 > 44: 91 23 00 00 stw r9,0(r3) > 48: 4e 80 00 20 blr > 4c: 39 20 01 11 li r9,273 > 50: 4b ff ff d0 b 20 > > > That is definitely more expensive, it implements a table of branches. Okay, will split out the PPC32 implementation that retains existing table look up method. Also planning to keep that inside same file (arch/powerpc/mm/mmap.c), unless you have a difference preference. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D9CA8C433F5 for ; Wed, 2 Mar 2022 03:22:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=wcMv5A+5InB/WxCkzI0omwG+DBcAB83HFP4RJsLnaz8=; b=paBcyCr0c7sUYj/XKrV2JWTtdf 0BRJOYSXjwVU0lu2N/feFrZrrS7BGSW56aDtd+EHQzIVKLRwGZFl1cJydQLJT/bvp8SYldySs346W fvgc0x4AhC8QQxilJJKm0NnQGchIP4bItidq++Hci1URKlxGSSEWa+2Ktodpw3e/fK64qIkMzCGA1 eZKZjcnQIukLJ7FYsQHTgYwhcdXnStuczeW6WdjoQUkiK21vrBSqcVVJI/sIgbJ2IWzOkx28Wz/0N GoRB1G5x4dzmS6ozdfkkLl6zNRip4crpHldYsjEQnypCCNa8ol2ikevPIWOwPx7K5u8z+aPyicdAd PC9dpINA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nPFZb-001IBA-VW; Wed, 02 Mar 2022 03:22:43 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nPFZK-001I54-VG; Wed, 02 Mar 2022 03:22:28 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D55FF11FB; Tue, 1 Mar 2022 19:22:25 -0800 (PST) Received: from [10.163.49.202] (unknown [10.163.49.202]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 000B23F73D; Tue, 1 Mar 2022 19:22:16 -0800 (PST) Subject: Re: [PATCH V3 09/30] arm/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT To: Christophe Leroy , "Russell King (Oracle)" Cc: "linux-ia64@vger.kernel.org" , "linux-sh@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-mm@kvack.org" , "sparclinux@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "linux-arch@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-hexagon@vger.kernel.org" , "linux-csky@vger.kernel.org" , Christoph Hellwig , "geert@linux-m68k.org" , "linux-snps-arc@lists.infradead.org" , "linux-xtensa@linux-xtensa.org" , Arnd Bergmann , "linux-um@lists.infradead.org" , "linux-m68k@lists.linux-m68k.org" , "openrisc@lists.librecores.org" , "linux-arm-kernel@lists.infradead.org" , "linux-parisc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-alpha@vger.kernel.org" , "akpm@linux-foundation.org" , "linuxppc-dev@lists.ozlabs.org" References: <1646045273-9343-1-git-send-email-anshuman.khandual@arm.com> <1646045273-9343-10-git-send-email-anshuman.khandual@arm.com> <542fa048-131e-240b-cc3a-fd4fff7ce4ba@arm.com> From: Anshuman Khandual Message-ID: Date: Wed, 2 Mar 2022 08:52:14 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220301_192227_127916_5371CA49 X-CRM114-Status: GOOD ( 19.58 ) X-BeenThere: linux-snps-arc@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux on Synopsys ARC Processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+linux-snps-arc=archiver.kernel.org@lists.infradead.org CgpPbiAzLzEvMjIgMTo0NiBQTSwgQ2hyaXN0b3BoZSBMZXJveSB3cm90ZToKPiAKPiAKPiBMZSAw MS8wMy8yMDIyIMOgIDAxOjMxLCBSdXNzZWxsIEtpbmcgKE9yYWNsZSkgYSDDqWNyaXTCoDoKPj4g T24gVHVlLCBNYXIgMDEsIDIwMjIgYXQgMDU6MzA6NDFBTSArMDUzMCwgQW5zaHVtYW4gS2hhbmR1 YWwgd3JvdGU6Cj4+PiBPbiAyLzI4LzIyIDQ6MjcgUE0sIFJ1c3NlbGwgS2luZyAoT3JhY2xlKSB3 cm90ZToKPj4+PiBPbiBNb24sIEZlYiAyOCwgMjAyMiBhdCAwNDoxNzozMlBNICswNTMwLCBBbnNo dW1hbiBLaGFuZHVhbCB3cm90ZToKPj4+Pj4gVGhpcyBkZWZpbmVzIGFuZCBleHBvcnRzIGEgcGxh dGZvcm0gc3BlY2lmaWMgY3VzdG9tIHZtX2dldF9wYWdlX3Byb3QoKSB2aWEKPj4+Pj4gc3Vic2Ny aWJpbmcgQVJDSF9IQVNfVk1fR0VUX1BBR0VfUFJPVC4gU3Vic2VxdWVudGx5IGFsbCBfX1NYWFgg YW5kIF9fUFhYWAo+Pj4+PiBtYWNyb3MgY2FuIGJlIGRyb3BwZWQgd2hpY2ggYXJlIG5vIGxvbmdl ciBuZWVkZWQuCj4+Pj4KPj4+PiBXaGF0IEkgd291bGQgcmVhbGx5IGxpa2UgdG8ga25vdyBpcyB3 aHkgaGF2aW5nIHRvIHJ1biBfY29kZV8gdG8gd29yayBvdXQKPj4+PiB3aGF0IHRoZSBwYWdlIHBy b3RlY3Rpb25zIG5lZWQgdG8gYmUgaXMgYmV0dGVyIHRoYW4gbG9va2luZyBpdCB1cCBpbiBhCj4+ Pj4gdGFibGUuCj4+Pj4KPj4+PiBOb3Qgb25seSBpcyB0aGlzIG1vcmUgZXhwZW5zaXZlIGluIHRl cm1zIG9mIENQVSBjeWNsZXMsIGl0IGFsc28gYnJpbmdzCj4+Pj4gYWRkaXRpb25hbCBjb2RlIHNp emUgd2l0aCBpdC4KPj4+Pgo+Pj4+IEknbSBzdHJ1Z2dsaW5nIHRvIHNlZSB3aGF0IHRoZSBiZW5l Zml0IGlzLgo+Pj4KPj4+IEN1cnJlbnRseSB2bV9nZXRfcGFnZV9wcm90KCkgaXMgYWxzbyBiZWlu ZyBfcnVuXyB0byBmZXRjaCByZXF1aXJlZCBwYWdlCj4+PiBwcm90ZWN0aW9uIHZhbHVlcy4gQWx0 aG91Z2ggdGhhdCBpcyBiZWluZyBydW4gaW4gdGhlIGNvcmUgTU0gYW5kIGZyb20gYQo+Pj4gcGxh dGZvcm0gcGVyc3BlY3RpdmUgX19TWFhYLCBfX1BYWFggYXJlIGp1c3QgYmVpbmcgZXhwb3J0ZWQg Zm9yIGEgdGFibGUuCj4+PiBMb29raW5nIGl0IHVwIGluIGEgdGFibGUgKGFuZCBhcHBseWluZyBt b3JlIGNvbnN0cnVjdHMgdGhlcmUgYWZ0ZXIpIGlzCj4+PiBub3QgbXVjaCBkaWZmZXJlbnQgdGhh biBhIGNsZWFuIHN3aXRjaCBjYXNlIHN0YXRlbWVudCBpbiB0ZXJtcyBvZiBDUFUKPj4+IHVzYWdl LiBTbyB0aGlzIGlzIG5vdCBtb3JlIGV4cGVuc2l2ZSBpbiB0ZXJtcyBvZiBDUFUgY3ljbGVzLgo+ Pgo+PiBJIGRpc2FncmVlLgo+IAo+IFNvIGRvIEkuCj4gCj4+Cj4+IEhvd2V2ZXIsIGxldCdzIGJh c2UgdGhpcyBkaXNhZ3JlZW1lbnQgb24gc29tZSBldmlkZW5jZS4gSGVyZSBpcyB0aGUKPj4gcHJl c2VudCAzMi1iaXQgQVJNIGltcGxlbWVudGF0aW9uOgo+Pgo+PiAwMDAwMDA0OCA8dm1fZ2V0X3Bh Z2VfcHJvdD46Cj4+ICAgICAgICA0ODogICAgICAgZTIwMDAwMGYgICAgICAgIGFuZCAgICAgcjAs IHIwLCAjMTUKPj4gICAgICAgIDRjOiAgICAgICBlMzAwMzAwMCAgICAgICAgbW92dyAgICByMywg IzAKPj4gICAgICAgICAgICAgICAgICAgICAgICAgIDRjOiBSX0FSTV9NT1ZXX0FCU19OQyAgIC5M QU5DSE9SMQo+PiAgICAgICAgNTA6ICAgICAgIGUzNDAzMDAwICAgICAgICBtb3Z0ICAgIHIzLCAj MAo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgNTA6IFJfQVJNX01PVlRfQUJTICAgICAgLkxB TkNIT1IxCj4+ICAgICAgICA1NDogICAgICAgZTc5MzAxMDAgICAgICAgIGxkciAgICAgcjAsIFty MywgcjAsIGxzbCAjMl0KPj4gICAgICAgIDU4OiAgICAgICBlMTJmZmYxZSAgICAgICAgYnggICAg ICBscgo+Pgo+PiBUaGF0IGlzIGZpdmUgaW5zdHJ1Y3Rpb25zIGxvbmcuCj4gCj4gT24gcHBjMzIg SSBnZXQ6Cj4gCj4gMDAwMDAwOTQgPHZtX2dldF9wYWdlX3Byb3Q+Ogo+ICAgICAgICA5NDoJM2Qg MjAgMDAgMDAgCWxpcyAgICAgcjksMAo+IAkJCTk2OiBSX1BQQ19BRERSMTZfSEEJLmRhdGEuLnJv X2FmdGVyX2luaXQKPiAgICAgICAgOTg6CTU0IDg0IDE2IGJhIAlybHdpbm0gIHI0LHI0LDIsMjYs MjkKPiAgICAgICAgOWM6CTM5IDI5IDAwIDAwIAlhZGRpICAgIHI5LHI5LDAKPiAJCQk5ZTogUl9Q UENfQUREUjE2X0xPCS5kYXRhLi5yb19hZnRlcl9pbml0Cj4gICAgICAgIGEwOgk3ZCAyOSAyMCAy ZSAJbHd6eCAgICByOSxyOSxyNAo+ICAgICAgICBhNDoJOTEgMjMgMDAgMDAgCXN0dyAgICAgcjks MChyMykKPiAgICAgICAgYTg6CTRlIDgwIDAwIDIwIAlibHIKPiAKPiAKPj4KPj4gUGxlYXNlIHNo b3cgdGhhdCB5b3VyIG5ldyBpbXBsZW1lbnRhdGlvbiBpcyBub3QgbW9yZSBleHBlbnNpdmUgb24K Pj4gMzItYml0IEFSTS4gUGxlYXNlIGRvIHNvIGJ5IGJ1aWxkaW5nIGEgMzItYml0IGtlcm5lbCwg YW5kIHByb3ZpZGluZwo+PiB0aGUgZGlzYXNzZW1ibHkuCj4gCj4gV2l0aCB5b3VyIHNlcmllcyBJ IGdldDoKPiAKPiAwMDAwMDAwMCA8dm1fZ2V0X3BhZ2VfcHJvdD46Cj4gICAgIDA6CTNkIDIwIDAw IDAwIAlsaXMgICAgIHI5LDAKPiAJCQkyOiBSX1BQQ19BRERSMTZfSEEJLnJvZGF0YQo+ICAgICA0 OgkzOSAyOSAwMCAwMCAJYWRkaSAgICByOSxyOSwwCj4gCQkJNjogUl9QUENfQUREUjE2X0xPCS5y b2RhdGEKPiAgICAgODoJNTQgODQgMTYgYmEgCXJsd2lubSAgcjQscjQsMiwyNiwyOQo+ICAgICBj Ogk3ZCA0OSAyMCAyZSAJbHd6eCAgICByMTAscjkscjQKPiAgICAxMDoJN2QgNGEgNGEgMTQgCWFk ZCAgICAgcjEwLHIxMCxyOQo+ICAgIDE0Ogk3ZCA0OSAwMyBhNiAJbXRjdHIgICByMTAKPiAgICAx ODoJNGUgODAgMDQgMjAgCWJjdHIKPiAgICAxYzoJMzkgMjAgMDMgMTUgCWxpICAgICAgcjksNzg5 Cj4gICAgMjA6CTkxIDIzIDAwIDAwIAlzdHcgICAgIHI5LDAocjMpCj4gICAgMjQ6CTRlIDgwIDAw IDIwIAlibHIKPiAgICAyODoJMzkgMjAgMDEgMTUgCWxpICAgICAgcjksMjc3Cj4gICAgMmM6CTkx IDIzIDAwIDAwIAlzdHcgICAgIHI5LDAocjMpCj4gICAgMzA6CTRlIDgwIDAwIDIwIAlibHIKPiAg ICAzNDoJMzkgMjAgMDcgMTUgCWxpICAgICAgcjksMTgxMwo+ICAgIDM4Ogk5MSAyMyAwMCAwMCAJ c3R3ICAgICByOSwwKHIzKQo+ICAgIDNjOgk0ZSA4MCAwMCAyMCAJYmxyCj4gICAgNDA6CTM5IDIw IDA1IDE1IAlsaSAgICAgIHI5LDEzMDEKPiAgICA0NDoJOTEgMjMgMDAgMDAgCXN0dyAgICAgcjks MChyMykKPiAgICA0ODoJNGUgODAgMDAgMjAgCWJscgo+ICAgIDRjOgkzOSAyMCAwMSAxMSAJbGkg ICAgICByOSwyNzMKPiAgICA1MDoJNGIgZmYgZmYgZDAgCWIgICAgICAgMjAgPHZtX2dldF9wYWdl X3Byb3QrMHgyMD4KPiAKPiAKPiBUaGF0IGlzIGRlZmluaXRlbHkgbW9yZSBleHBlbnNpdmUsIGl0 IGltcGxlbWVudHMgYSB0YWJsZSBvZiBicmFuY2hlcy4KCk9rYXksIHdpbGwgc3BsaXQgb3V0IHRo ZSBQUEMzMiBpbXBsZW1lbnRhdGlvbiB0aGF0IHJldGFpbnMgZXhpc3RpbmcKdGFibGUgbG9vayB1 cCBtZXRob2QuIEFsc28gcGxhbm5pbmcgdG8ga2VlcCB0aGF0IGluc2lkZSBzYW1lIGZpbGUKKGFy Y2gvcG93ZXJwYy9tbS9tbWFwLmMpLCB1bmxlc3MgeW91IGhhdmUgYSBkaWZmZXJlbmNlIHByZWZl cmVuY2UuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwps aW51eC1zbnBzLWFyYyBtYWlsaW5nIGxpc3QKbGludXgtc25wcy1hcmNAbGlzdHMuaW5mcmFkZWFk Lm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LXNu cHMtYXJjCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6B606C433F5 for ; Wed, 2 Mar 2022 03:23:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=9KEBDGaiCLpB4a+GMriT4DWOgzQo1LOoLP87BFRa+20=; b=H7NwXAdDUXLtQ1i8Jax2tzI5YS 8+vVsNyPtox7kV3S7iSSzcVK61QwdbC9kxuXrS6mOUe6bNImqjlbmbh7IsfgqUpf1igoG5+Q+lTU1 oABTVTRzGhtJU7a4Xird/sHtXhtQ7a5NyWjgDZJx+gAAy3u06N6MSV73OSJw2+JE2o+L6ezpe8xET KLNBzevPlzx2KFy7Fv0DP+X/oUFydbYb8DUupHFmFJEcOCYUcT+0K/b2E89Hkq7zTdAMAll9MS4wI yq7/m6fOXQnS/WT46UgRwnYzenJVG7ArGVTy7HrkybGpBWF5tKD/BDCrCjIbgk00GKx6AWeVgKtjp PoWb3fDQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nPFZO-001I71-Vl; Wed, 02 Mar 2022 03:22:31 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nPFZK-001I54-VG; Wed, 02 Mar 2022 03:22:28 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D55FF11FB; Tue, 1 Mar 2022 19:22:25 -0800 (PST) Received: from [10.163.49.202] (unknown [10.163.49.202]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 000B23F73D; Tue, 1 Mar 2022 19:22:16 -0800 (PST) Subject: Re: [PATCH V3 09/30] arm/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT To: Christophe Leroy , "Russell King (Oracle)" Cc: "linux-ia64@vger.kernel.org" , "linux-sh@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-mm@kvack.org" , "sparclinux@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "linux-arch@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-hexagon@vger.kernel.org" , "linux-csky@vger.kernel.org" , Christoph Hellwig , "geert@linux-m68k.org" , "linux-snps-arc@lists.infradead.org" , "linux-xtensa@linux-xtensa.org" , Arnd Bergmann , "linux-um@lists.infradead.org" , "linux-m68k@lists.linux-m68k.org" , "openrisc@lists.librecores.org" , "linux-arm-kernel@lists.infradead.org" , "linux-parisc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-alpha@vger.kernel.org" , "akpm@linux-foundation.org" , "linuxppc-dev@lists.ozlabs.org" References: <1646045273-9343-1-git-send-email-anshuman.khandual@arm.com> <1646045273-9343-10-git-send-email-anshuman.khandual@arm.com> <542fa048-131e-240b-cc3a-fd4fff7ce4ba@arm.com> From: Anshuman Khandual Message-ID: Date: Wed, 2 Mar 2022 08:52:14 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220301_192227_127916_5371CA49 X-CRM114-Status: GOOD ( 19.58 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org CgpPbiAzLzEvMjIgMTo0NiBQTSwgQ2hyaXN0b3BoZSBMZXJveSB3cm90ZToKPiAKPiAKPiBMZSAw MS8wMy8yMDIyIMOgIDAxOjMxLCBSdXNzZWxsIEtpbmcgKE9yYWNsZSkgYSDDqWNyaXTCoDoKPj4g T24gVHVlLCBNYXIgMDEsIDIwMjIgYXQgMDU6MzA6NDFBTSArMDUzMCwgQW5zaHVtYW4gS2hhbmR1 YWwgd3JvdGU6Cj4+PiBPbiAyLzI4LzIyIDQ6MjcgUE0sIFJ1c3NlbGwgS2luZyAoT3JhY2xlKSB3 cm90ZToKPj4+PiBPbiBNb24sIEZlYiAyOCwgMjAyMiBhdCAwNDoxNzozMlBNICswNTMwLCBBbnNo dW1hbiBLaGFuZHVhbCB3cm90ZToKPj4+Pj4gVGhpcyBkZWZpbmVzIGFuZCBleHBvcnRzIGEgcGxh dGZvcm0gc3BlY2lmaWMgY3VzdG9tIHZtX2dldF9wYWdlX3Byb3QoKSB2aWEKPj4+Pj4gc3Vic2Ny aWJpbmcgQVJDSF9IQVNfVk1fR0VUX1BBR0VfUFJPVC4gU3Vic2VxdWVudGx5IGFsbCBfX1NYWFgg YW5kIF9fUFhYWAo+Pj4+PiBtYWNyb3MgY2FuIGJlIGRyb3BwZWQgd2hpY2ggYXJlIG5vIGxvbmdl ciBuZWVkZWQuCj4+Pj4KPj4+PiBXaGF0IEkgd291bGQgcmVhbGx5IGxpa2UgdG8ga25vdyBpcyB3 aHkgaGF2aW5nIHRvIHJ1biBfY29kZV8gdG8gd29yayBvdXQKPj4+PiB3aGF0IHRoZSBwYWdlIHBy b3RlY3Rpb25zIG5lZWQgdG8gYmUgaXMgYmV0dGVyIHRoYW4gbG9va2luZyBpdCB1cCBpbiBhCj4+ Pj4gdGFibGUuCj4+Pj4KPj4+PiBOb3Qgb25seSBpcyB0aGlzIG1vcmUgZXhwZW5zaXZlIGluIHRl cm1zIG9mIENQVSBjeWNsZXMsIGl0IGFsc28gYnJpbmdzCj4+Pj4gYWRkaXRpb25hbCBjb2RlIHNp emUgd2l0aCBpdC4KPj4+Pgo+Pj4+IEknbSBzdHJ1Z2dsaW5nIHRvIHNlZSB3aGF0IHRoZSBiZW5l Zml0IGlzLgo+Pj4KPj4+IEN1cnJlbnRseSB2bV9nZXRfcGFnZV9wcm90KCkgaXMgYWxzbyBiZWlu ZyBfcnVuXyB0byBmZXRjaCByZXF1aXJlZCBwYWdlCj4+PiBwcm90ZWN0aW9uIHZhbHVlcy4gQWx0 aG91Z2ggdGhhdCBpcyBiZWluZyBydW4gaW4gdGhlIGNvcmUgTU0gYW5kIGZyb20gYQo+Pj4gcGxh dGZvcm0gcGVyc3BlY3RpdmUgX19TWFhYLCBfX1BYWFggYXJlIGp1c3QgYmVpbmcgZXhwb3J0ZWQg Zm9yIGEgdGFibGUuCj4+PiBMb29raW5nIGl0IHVwIGluIGEgdGFibGUgKGFuZCBhcHBseWluZyBt b3JlIGNvbnN0cnVjdHMgdGhlcmUgYWZ0ZXIpIGlzCj4+PiBub3QgbXVjaCBkaWZmZXJlbnQgdGhh biBhIGNsZWFuIHN3aXRjaCBjYXNlIHN0YXRlbWVudCBpbiB0ZXJtcyBvZiBDUFUKPj4+IHVzYWdl LiBTbyB0aGlzIGlzIG5vdCBtb3JlIGV4cGVuc2l2ZSBpbiB0ZXJtcyBvZiBDUFUgY3ljbGVzLgo+ Pgo+PiBJIGRpc2FncmVlLgo+IAo+IFNvIGRvIEkuCj4gCj4+Cj4+IEhvd2V2ZXIsIGxldCdzIGJh c2UgdGhpcyBkaXNhZ3JlZW1lbnQgb24gc29tZSBldmlkZW5jZS4gSGVyZSBpcyB0aGUKPj4gcHJl c2VudCAzMi1iaXQgQVJNIGltcGxlbWVudGF0aW9uOgo+Pgo+PiAwMDAwMDA0OCA8dm1fZ2V0X3Bh Z2VfcHJvdD46Cj4+ICAgICAgICA0ODogICAgICAgZTIwMDAwMGYgICAgICAgIGFuZCAgICAgcjAs IHIwLCAjMTUKPj4gICAgICAgIDRjOiAgICAgICBlMzAwMzAwMCAgICAgICAgbW92dyAgICByMywg IzAKPj4gICAgICAgICAgICAgICAgICAgICAgICAgIDRjOiBSX0FSTV9NT1ZXX0FCU19OQyAgIC5M QU5DSE9SMQo+PiAgICAgICAgNTA6ICAgICAgIGUzNDAzMDAwICAgICAgICBtb3Z0ICAgIHIzLCAj MAo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgNTA6IFJfQVJNX01PVlRfQUJTICAgICAgLkxB TkNIT1IxCj4+ICAgICAgICA1NDogICAgICAgZTc5MzAxMDAgICAgICAgIGxkciAgICAgcjAsIFty MywgcjAsIGxzbCAjMl0KPj4gICAgICAgIDU4OiAgICAgICBlMTJmZmYxZSAgICAgICAgYnggICAg ICBscgo+Pgo+PiBUaGF0IGlzIGZpdmUgaW5zdHJ1Y3Rpb25zIGxvbmcuCj4gCj4gT24gcHBjMzIg SSBnZXQ6Cj4gCj4gMDAwMDAwOTQgPHZtX2dldF9wYWdlX3Byb3Q+Ogo+ICAgICAgICA5NDoJM2Qg MjAgMDAgMDAgCWxpcyAgICAgcjksMAo+IAkJCTk2OiBSX1BQQ19BRERSMTZfSEEJLmRhdGEuLnJv X2FmdGVyX2luaXQKPiAgICAgICAgOTg6CTU0IDg0IDE2IGJhIAlybHdpbm0gIHI0LHI0LDIsMjYs MjkKPiAgICAgICAgOWM6CTM5IDI5IDAwIDAwIAlhZGRpICAgIHI5LHI5LDAKPiAJCQk5ZTogUl9Q UENfQUREUjE2X0xPCS5kYXRhLi5yb19hZnRlcl9pbml0Cj4gICAgICAgIGEwOgk3ZCAyOSAyMCAy ZSAJbHd6eCAgICByOSxyOSxyNAo+ICAgICAgICBhNDoJOTEgMjMgMDAgMDAgCXN0dyAgICAgcjks MChyMykKPiAgICAgICAgYTg6CTRlIDgwIDAwIDIwIAlibHIKPiAKPiAKPj4KPj4gUGxlYXNlIHNo b3cgdGhhdCB5b3VyIG5ldyBpbXBsZW1lbnRhdGlvbiBpcyBub3QgbW9yZSBleHBlbnNpdmUgb24K Pj4gMzItYml0IEFSTS4gUGxlYXNlIGRvIHNvIGJ5IGJ1aWxkaW5nIGEgMzItYml0IGtlcm5lbCwg YW5kIHByb3ZpZGluZwo+PiB0aGUgZGlzYXNzZW1ibHkuCj4gCj4gV2l0aCB5b3VyIHNlcmllcyBJ IGdldDoKPiAKPiAwMDAwMDAwMCA8dm1fZ2V0X3BhZ2VfcHJvdD46Cj4gICAgIDA6CTNkIDIwIDAw IDAwIAlsaXMgICAgIHI5LDAKPiAJCQkyOiBSX1BQQ19BRERSMTZfSEEJLnJvZGF0YQo+ICAgICA0 OgkzOSAyOSAwMCAwMCAJYWRkaSAgICByOSxyOSwwCj4gCQkJNjogUl9QUENfQUREUjE2X0xPCS5y b2RhdGEKPiAgICAgODoJNTQgODQgMTYgYmEgCXJsd2lubSAgcjQscjQsMiwyNiwyOQo+ICAgICBj Ogk3ZCA0OSAyMCAyZSAJbHd6eCAgICByMTAscjkscjQKPiAgICAxMDoJN2QgNGEgNGEgMTQgCWFk ZCAgICAgcjEwLHIxMCxyOQo+ICAgIDE0Ogk3ZCA0OSAwMyBhNiAJbXRjdHIgICByMTAKPiAgICAx ODoJNGUgODAgMDQgMjAgCWJjdHIKPiAgICAxYzoJMzkgMjAgMDMgMTUgCWxpICAgICAgcjksNzg5 Cj4gICAgMjA6CTkxIDIzIDAwIDAwIAlzdHcgICAgIHI5LDAocjMpCj4gICAgMjQ6CTRlIDgwIDAw IDIwIAlibHIKPiAgICAyODoJMzkgMjAgMDEgMTUgCWxpICAgICAgcjksMjc3Cj4gICAgMmM6CTkx IDIzIDAwIDAwIAlzdHcgICAgIHI5LDAocjMpCj4gICAgMzA6CTRlIDgwIDAwIDIwIAlibHIKPiAg ICAzNDoJMzkgMjAgMDcgMTUgCWxpICAgICAgcjksMTgxMwo+ICAgIDM4Ogk5MSAyMyAwMCAwMCAJ c3R3ICAgICByOSwwKHIzKQo+ICAgIDNjOgk0ZSA4MCAwMCAyMCAJYmxyCj4gICAgNDA6CTM5IDIw IDA1IDE1IAlsaSAgICAgIHI5LDEzMDEKPiAgICA0NDoJOTEgMjMgMDAgMDAgCXN0dyAgICAgcjks MChyMykKPiAgICA0ODoJNGUgODAgMDAgMjAgCWJscgo+ICAgIDRjOgkzOSAyMCAwMSAxMSAJbGkg ICAgICByOSwyNzMKPiAgICA1MDoJNGIgZmYgZmYgZDAgCWIgICAgICAgMjAgPHZtX2dldF9wYWdl X3Byb3QrMHgyMD4KPiAKPiAKPiBUaGF0IGlzIGRlZmluaXRlbHkgbW9yZSBleHBlbnNpdmUsIGl0 IGltcGxlbWVudHMgYSB0YWJsZSBvZiBicmFuY2hlcy4KCk9rYXksIHdpbGwgc3BsaXQgb3V0IHRo ZSBQUEMzMiBpbXBsZW1lbnRhdGlvbiB0aGF0IHJldGFpbnMgZXhpc3RpbmcKdGFibGUgbG9vayB1 cCBtZXRob2QuIEFsc28gcGxhbm5pbmcgdG8ga2VlcCB0aGF0IGluc2lkZSBzYW1lIGZpbGUKKGFy Y2gvcG93ZXJwYy9tbS9tbWFwLmMpLCB1bmxlc3MgeW91IGhhdmUgYSBkaWZmZXJlbmNlIHByZWZl cmVuY2UuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwps aW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJh ZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51 eC1hcm0ta2VybmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anshuman Khandual Date: Wed, 2 Mar 2022 08:52:14 +0530 Subject: [OpenRISC] [PATCH V3 09/30] arm/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT In-Reply-To: References: <1646045273-9343-1-git-send-email-anshuman.khandual@arm.com> <1646045273-9343-10-git-send-email-anshuman.khandual@arm.com> <542fa048-131e-240b-cc3a-fd4fff7ce4ba@arm.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: openrisc@lists.librecores.org On 3/1/22 1:46 PM, Christophe Leroy wrote: > > > Le 01/03/2022 à 01:31, Russell King (Oracle) a écrit : >> On Tue, Mar 01, 2022 at 05:30:41AM +0530, Anshuman Khandual wrote: >>> On 2/28/22 4:27 PM, Russell King (Oracle) wrote: >>>> On Mon, Feb 28, 2022 at 04:17:32PM +0530, Anshuman Khandual wrote: >>>>> This defines and exports a platform specific custom vm_get_page_prot() via >>>>> subscribing ARCH_HAS_VM_GET_PAGE_PROT. Subsequently all __SXXX and __PXXX >>>>> macros can be dropped which are no longer needed. >>>> >>>> What I would really like to know is why having to run _code_ to work out >>>> what the page protections need to be is better than looking it up in a >>>> table. >>>> >>>> Not only is this more expensive in terms of CPU cycles, it also brings >>>> additional code size with it. >>>> >>>> I'm struggling to see what the benefit is. >>> >>> Currently vm_get_page_prot() is also being _run_ to fetch required page >>> protection values. Although that is being run in the core MM and from a >>> platform perspective __SXXX, __PXXX are just being exported for a table. >>> Looking it up in a table (and applying more constructs there after) is >>> not much different than a clean switch case statement in terms of CPU >>> usage. So this is not more expensive in terms of CPU cycles. >> >> I disagree. > > So do I. > >> >> However, let's base this disagreement on some evidence. Here is the >> present 32-bit ARM implementation: >> >> 00000048 : >> 48: e200000f and r0, r0, #15 >> 4c: e3003000 movw r3, #0 >> 4c: R_ARM_MOVW_ABS_NC .LANCHOR1 >> 50: e3403000 movt r3, #0 >> 50: R_ARM_MOVT_ABS .LANCHOR1 >> 54: e7930100 ldr r0, [r3, r0, lsl #2] >> 58: e12fff1e bx lr >> >> That is five instructions long. > > On ppc32 I get: > > 00000094 : > 94: 3d 20 00 00 lis r9,0 > 96: R_PPC_ADDR16_HA .data..ro_after_init > 98: 54 84 16 ba rlwinm r4,r4,2,26,29 > 9c: 39 29 00 00 addi r9,r9,0 > 9e: R_PPC_ADDR16_LO .data..ro_after_init > a0: 7d 29 20 2e lwzx r9,r9,r4 > a4: 91 23 00 00 stw r9,0(r3) > a8: 4e 80 00 20 blr > > >> >> Please show that your new implementation is not more expensive on >> 32-bit ARM. Please do so by building a 32-bit kernel, and providing >> the disassembly. > > With your series I get: > > 00000000 : > 0: 3d 20 00 00 lis r9,0 > 2: R_PPC_ADDR16_HA .rodata > 4: 39 29 00 00 addi r9,r9,0 > 6: R_PPC_ADDR16_LO .rodata > 8: 54 84 16 ba rlwinm r4,r4,2,26,29 > c: 7d 49 20 2e lwzx r10,r9,r4 > 10: 7d 4a 4a 14 add r10,r10,r9 > 14: 7d 49 03 a6 mtctr r10 > 18: 4e 80 04 20 bctr > 1c: 39 20 03 15 li r9,789 > 20: 91 23 00 00 stw r9,0(r3) > 24: 4e 80 00 20 blr > 28: 39 20 01 15 li r9,277 > 2c: 91 23 00 00 stw r9,0(r3) > 30: 4e 80 00 20 blr > 34: 39 20 07 15 li r9,1813 > 38: 91 23 00 00 stw r9,0(r3) > 3c: 4e 80 00 20 blr > 40: 39 20 05 15 li r9,1301 > 44: 91 23 00 00 stw r9,0(r3) > 48: 4e 80 00 20 blr > 4c: 39 20 01 11 li r9,273 > 50: 4b ff ff d0 b 20 > > > That is definitely more expensive, it implements a table of branches. Okay, will split out the PPC32 implementation that retains existing table look up method. Also planning to keep that inside same file (arch/powerpc/mm/mmap.c), unless you have a difference preference. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anshuman Khandual Date: Wed, 02 Mar 2022 03:34:14 +0000 Subject: Re: [PATCH V3 09/30] arm/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT Message-Id: List-Id: References: <1646045273-9343-1-git-send-email-anshuman.khandual@arm.com> <1646045273-9343-10-git-send-email-anshuman.khandual@arm.com> <542fa048-131e-240b-cc3a-fd4fff7ce4ba@arm.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: Christophe Leroy , "Russell King (Oracle)" Cc: "linux-ia64@vger.kernel.org" , "linux-sh@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-mm@kvack.org" , "sparclinux@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "linux-arch@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-hexagon@vger.kernel.org" , "linux-csky@vger.kernel.org" , Christoph Hellwig , "geert@linux-m68k.org" , "linux-snps-arc@lists.infradead.org" , "linux-xtensa@linux-xtensa.org" , Arnd Bergmann , "linux-um@lists.infradead.org" , "linux-m68k@lists.linux-m68k.org" , "openrisc@lists.librecores.org" , "linux-arm-kernel@lists.infradead.org" , "linux-parisc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-alpha@vger.kernel.org" , "akpm@linux-foundation.org" , "linuxppc-dev@lists.ozlabs.org" On 3/1/22 1:46 PM, Christophe Leroy wrote: > > > Le 01/03/2022 à 01:31, Russell King (Oracle) a écrit : >> On Tue, Mar 01, 2022 at 05:30:41AM +0530, Anshuman Khandual wrote: >>> On 2/28/22 4:27 PM, Russell King (Oracle) wrote: >>>> On Mon, Feb 28, 2022 at 04:17:32PM +0530, Anshuman Khandual wrote: >>>>> This defines and exports a platform specific custom vm_get_page_prot() via >>>>> subscribing ARCH_HAS_VM_GET_PAGE_PROT. Subsequently all __SXXX and __PXXX >>>>> macros can be dropped which are no longer needed. >>>> >>>> What I would really like to know is why having to run _code_ to work out >>>> what the page protections need to be is better than looking it up in a >>>> table. >>>> >>>> Not only is this more expensive in terms of CPU cycles, it also brings >>>> additional code size with it. >>>> >>>> I'm struggling to see what the benefit is. >>> >>> Currently vm_get_page_prot() is also being _run_ to fetch required page >>> protection values. Although that is being run in the core MM and from a >>> platform perspective __SXXX, __PXXX are just being exported for a table. >>> Looking it up in a table (and applying more constructs there after) is >>> not much different than a clean switch case statement in terms of CPU >>> usage. So this is not more expensive in terms of CPU cycles. >> >> I disagree. > > So do I. > >> >> However, let's base this disagreement on some evidence. Here is the >> present 32-bit ARM implementation: >> >> 00000048 : >> 48: e200000f and r0, r0, #15 >> 4c: e3003000 movw r3, #0 >> 4c: R_ARM_MOVW_ABS_NC .LANCHOR1 >> 50: e3403000 movt r3, #0 >> 50: R_ARM_MOVT_ABS .LANCHOR1 >> 54: e7930100 ldr r0, [r3, r0, lsl #2] >> 58: e12fff1e bx lr >> >> That is five instructions long. > > On ppc32 I get: > > 00000094 : > 94: 3d 20 00 00 lis r9,0 > 96: R_PPC_ADDR16_HA .data..ro_after_init > 98: 54 84 16 ba rlwinm r4,r4,2,26,29 > 9c: 39 29 00 00 addi r9,r9,0 > 9e: R_PPC_ADDR16_LO .data..ro_after_init > a0: 7d 29 20 2e lwzx r9,r9,r4 > a4: 91 23 00 00 stw r9,0(r3) > a8: 4e 80 00 20 blr > > >> >> Please show that your new implementation is not more expensive on >> 32-bit ARM. Please do so by building a 32-bit kernel, and providing >> the disassembly. > > With your series I get: > > 00000000 : > 0: 3d 20 00 00 lis r9,0 > 2: R_PPC_ADDR16_HA .rodata > 4: 39 29 00 00 addi r9,r9,0 > 6: R_PPC_ADDR16_LO .rodata > 8: 54 84 16 ba rlwinm r4,r4,2,26,29 > c: 7d 49 20 2e lwzx r10,r9,r4 > 10: 7d 4a 4a 14 add r10,r10,r9 > 14: 7d 49 03 a6 mtctr r10 > 18: 4e 80 04 20 bctr > 1c: 39 20 03 15 li r9,789 > 20: 91 23 00 00 stw r9,0(r3) > 24: 4e 80 00 20 blr > 28: 39 20 01 15 li r9,277 > 2c: 91 23 00 00 stw r9,0(r3) > 30: 4e 80 00 20 blr > 34: 39 20 07 15 li r9,1813 > 38: 91 23 00 00 stw r9,0(r3) > 3c: 4e 80 00 20 blr > 40: 39 20 05 15 li r9,1301 > 44: 91 23 00 00 stw r9,0(r3) > 48: 4e 80 00 20 blr > 4c: 39 20 01 11 li r9,273 > 50: 4b ff ff d0 b 20 > > > That is definitely more expensive, it implements a table of branches. Okay, will split out the PPC32 implementation that retains existing table look up method. Also planning to keep that inside same file (arch/powerpc/mm/mmap.c), unless you have a difference preference. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anshuman Khandual Subject: Re: [PATCH V3 09/30] arm/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT Date: Wed, 2 Mar 2022 08:52:14 +0530 Message-ID: References: <1646045273-9343-1-git-send-email-anshuman.khandual@arm.com> <1646045273-9343-10-git-send-email-anshuman.khandual@arm.com> <542fa048-131e-240b-cc3a-fd4fff7ce4ba@arm.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: Content-Language: en-US List-ID: Content-Type: text/plain; charset="utf-8" To: Christophe Leroy , "Russell King (Oracle)" Cc: "linux-ia64@vger.kernel.org" , "linux-sh@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-mm@kvack.org" , "sparclinux@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "linux-arch@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-hexagon@vger.kernel.org" , "linux-csky@vger.kernel.org" , Christoph Hellwig , "geert@linux-m68k.org" , "linux-snps-arc@lists.infradead.org" , "linux-xtensa@linux-xtensa.org" On 3/1/22 1:46 PM, Christophe Leroy wrote: > > > Le 01/03/2022 à 01:31, Russell King (Oracle) a écrit : >> On Tue, Mar 01, 2022 at 05:30:41AM +0530, Anshuman Khandual wrote: >>> On 2/28/22 4:27 PM, Russell King (Oracle) wrote: >>>> On Mon, Feb 28, 2022 at 04:17:32PM +0530, Anshuman Khandual wrote: >>>>> This defines and exports a platform specific custom vm_get_page_prot() via >>>>> subscribing ARCH_HAS_VM_GET_PAGE_PROT. Subsequently all __SXXX and __PXXX >>>>> macros can be dropped which are no longer needed. >>>> >>>> What I would really like to know is why having to run _code_ to work out >>>> what the page protections need to be is better than looking it up in a >>>> table. >>>> >>>> Not only is this more expensive in terms of CPU cycles, it also brings >>>> additional code size with it. >>>> >>>> I'm struggling to see what the benefit is. >>> >>> Currently vm_get_page_prot() is also being _run_ to fetch required page >>> protection values. Although that is being run in the core MM and from a >>> platform perspective __SXXX, __PXXX are just being exported for a table. >>> Looking it up in a table (and applying more constructs there after) is >>> not much different than a clean switch case statement in terms of CPU >>> usage. So this is not more expensive in terms of CPU cycles. >> >> I disagree. > > So do I. > >> >> However, let's base this disagreement on some evidence. Here is the >> present 32-bit ARM implementation: >> >> 00000048 : >> 48: e200000f and r0, r0, #15 >> 4c: e3003000 movw r3, #0 >> 4c: R_ARM_MOVW_ABS_NC .LANCHOR1 >> 50: e3403000 movt r3, #0 >> 50: R_ARM_MOVT_ABS .LANCHOR1 >> 54: e7930100 ldr r0, [r3, r0, lsl #2] >> 58: e12fff1e bx lr >> >> That is five instructions long. > > On ppc32 I get: > > 00000094 : > 94: 3d 20 00 00 lis r9,0 > 96: R_PPC_ADDR16_HA .data..ro_after_init > 98: 54 84 16 ba rlwinm r4,r4,2,26,29 > 9c: 39 29 00 00 addi r9,r9,0 > 9e: R_PPC_ADDR16_LO .data..ro_after_init > a0: 7d 29 20 2e lwzx r9,r9,r4 > a4: 91 23 00 00 stw r9,0(r3) > a8: 4e 80 00 20 blr > > >> >> Please show that your new implementation is not more expensive on >> 32-bit ARM. Please do so by building a 32-bit kernel, and providing >> the disassembly. > > With your series I get: > > 00000000 : > 0: 3d 20 00 00 lis r9,0 > 2: R_PPC_ADDR16_HA .rodata > 4: 39 29 00 00 addi r9,r9,0 > 6: R_PPC_ADDR16_LO .rodata > 8: 54 84 16 ba rlwinm r4,r4,2,26,29 > c: 7d 49 20 2e lwzx r10,r9,r4 > 10: 7d 4a 4a 14 add r10,r10,r9 > 14: 7d 49 03 a6 mtctr r10 > 18: 4e 80 04 20 bctr > 1c: 39 20 03 15 li r9,789 > 20: 91 23 00 00 stw r9,0(r3) > 24: 4e 80 00 20 blr > 28: 39 20 01 15 li r9,277 > 2c: 91 23 00 00 stw r9,0(r3) > 30: 4e 80 00 20 blr > 34: 39 20 07 15 li r9,1813 > 38: 91 23 00 00 stw r9,0(r3) > 3c: 4e 80 00 20 blr > 40: 39 20 05 15 li r9,1301 > 44: 91 23 00 00 stw r9,0(r3) > 48: 4e 80 00 20 blr > 4c: 39 20 01 11 li r9,273 > 50: 4b ff ff d0 b 20 > > > That is definitely more expensive, it implements a table of branches. Okay, will split out the PPC32 implementation that retains existing table look up method. Also planning to keep that inside same file (arch/powerpc/mm/mmap.c), unless you have a difference preference.