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 2AEC5C04A95 for ; Mon, 26 Sep 2022 03:19:42 +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:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=WLR6bKMssucJxVoSZw0fydJnzKxRB6PHdnWsTGzwMeM=; b=iLrSLZ3ksdVb3J lir4y6gkGF+hD9EKyIcXMtnZJN3whGXOkbRtpMbbgI5zImDvRGpIHNflRKaa0UiTFSfl7GOYI7dni WjskW34PgAtYaakOst08dqSIO2t/4cg0BuOBqiU8oVP166CILA23YrLup5uGhsUXW7N2wb1kYgtj9 e+UL7Kvsl18Y8nmiRSPAknMlsJcW+RgfAP7oB/HrD7pmrSkV8RltjdcLBg4C5pFmUI4BY0V3WiK/v 31AZzMwhK2QiZX+2uG54xmbd/8daKcs/Vh0m8Tc/GhVPsOtdDyQ3IA8EGCXg+OqTaC/6UAtT1UPOa KN8AlGE3tA0nCuaaRcKA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ocedh-001K07-1B; Mon, 26 Sep 2022 03:18:37 +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 1ocedc-001JyT-Hg for linux-arm-kernel@lists.infradead.org; Mon, 26 Sep 2022 03:18:34 +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 7CA261063; Sun, 25 Sep 2022 20:18:33 -0700 (PDT) Received: from [10.162.42.7] (unknown [10.162.42.7]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 328493F73D; Sun, 25 Sep 2022 20:18:24 -0700 (PDT) Message-ID: <089026ad-7569-c173-301a-5de2f107a823@arm.com> Date: Mon, 26 Sep 2022 08:48:22 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] arm64/mm: Drop ARM64_KERNEL_USES_PMD_MAPS Content-Language: en-US To: Joey Gouly Cc: linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , nd@arm.com References: <20220923130841.1382741-1-anshuman.khandual@arm.com> <20220923133802.GA22477@e124191.cambridge.arm.com> From: Anshuman Khandual In-Reply-To: <20220923133802.GA22477@e124191.cambridge.arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220925_201832_714702_D3FD8F73 X-CRM114-Status: GOOD ( 24.09 ) 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="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 9/23/22 19:08, Joey Gouly wrote: > Hi Anshuman, > > On Fri, Sep 23, 2022 at 06:38:41PM +0530, Anshuman Khandual wrote: >> Currently ARM64_KERNEL_USES_PMD_MAPS is an unnecessary abstraction. Kernel >> mapping at PMD (aka huge page aka block) level, is only applicable with 4K >> base page, which makes it 2MB aligned, a necessary requirement for linear >> mapping and physical memory start address. This can be easily achieved by >> directly checking against base page size itself. This drops off the macro >> ARM64_KERNE_USES_PMD_MAPS which is redundant. >> >> Cc: Catalin Marinas >> Cc: Will Deacon >> Cc: linux-arm-kernel@lists.infradead.org >> Signed-off-by: Anshuman Khandual >> --- >> This applies on v6.0-rc6 after the following patch. >> >> https://lore.kernel.org/all/20220920014951.196191-1-wangkefeng.wang@huawei.com/ >> >> arch/arm64/include/asm/kernel-pgtable.h | 33 +++++++++---------------- >> arch/arm64/mm/mmu.c | 2 +- >> 2 files changed, 12 insertions(+), 23 deletions(-) >> >> diff --git a/arch/arm64/include/asm/kernel-pgtable.h b/arch/arm64/include/asm/kernel-pgtable.h >> index 32d14f481f0c..5c2f72bae2ca 100644 >> --- a/arch/arm64/include/asm/kernel-pgtable.h >> +++ b/arch/arm64/include/asm/kernel-pgtable.h >> @@ -18,11 +18,6 @@ >> * with 4K (section size = 2M) but not with 16K (section size = 32M) or >> * 64K (section size = 512M). >> */ >> -#ifdef CONFIG_ARM64_4K_PAGES >> -#define ARM64_KERNEL_USES_PMD_MAPS 1 >> -#else >> -#define ARM64_KERNEL_USES_PMD_MAPS 0 >> -#endif > > There is now a dangling comment above this. I think it's quite a useful comment, > so could be moved elsewhere if possible. I have collected both these relevant comment paragraphs before the 4K switch. > > Or maybe just keep ARM64_KERNEL_USES_PMD_MAPS because it's not a big abstraction > and it's more obvious to why there's differences in SWAPPER_BLOCK_SIZE etc. The decision about kernel mapping granularity is static i.e depends just on base page size. If that decision needs to be remembered at all in form of an abstraction, it can be achieved via a new config option such as the following rather than a macro. config ARM64_KERNEL_USES_PMD_MAPS default y depends on CONFIG_ARM64_4K_PAGES > >> >> /* >> * The idmap and swapper page tables need some space reserved in the kernel >> @@ -34,10 +29,20 @@ >> * VA range, so pages required to map highest possible PA are reserved in all >> * cases. >> */ >> -#if ARM64_KERNEL_USES_PMD_MAPS >> +#ifdef CONFIG_ARM64_4K_PAGES >> #define SWAPPER_PGTABLE_LEVELS (CONFIG_PGTABLE_LEVELS - 1) >> +#define SWAPPER_BLOCK_SHIFT PMD_SHIFT >> +#define SWAPPER_BLOCK_SIZE PMD_SIZE >> +#define SWAPPER_TABLE_SHIFT PUD_SHIFT >> +#define SWAPPER_RW_MMUFLAGS (PMD_ATTRINDX(MT_NORMAL) | SWAPPER_PMD_FLAGS) >> +#define SWAPPER_RX_MMUFLAGS (SWAPPER_RW_MMUFLAGS | PMD_SECT_RDONLY) >> #else >> #define SWAPPER_PGTABLE_LEVELS (CONFIG_PGTABLE_LEVELS) >> +#define SWAPPER_BLOCK_SHIFT PAGE_SHIFT >> +#define SWAPPER_BLOCK_SIZE PAGE_SIZE >> +#define SWAPPER_TABLE_SHIFT PMD_SHIFT >> +#define SWAPPER_RW_MMUFLAGS (PTE_ATTRINDX(MT_NORMAL) | SWAPPER_PTE_FLAGS) >> +#define SWAPPER_RX_MMUFLAGS (SWAPPER_RW_MMUFLAGS | PTE_RDONLY) >> #endif >> >> >> @@ -96,15 +101,6 @@ >> #define INIT_IDMAP_DIR_PAGES EARLY_PAGES(KIMAGE_VADDR, _end + MAX_FDT_SIZE + SWAPPER_BLOCK_SIZE, 1) >> >> /* Initial memory map size */ >> -#if ARM64_KERNEL_USES_PMD_MAPS >> -#define SWAPPER_BLOCK_SHIFT PMD_SHIFT >> -#define SWAPPER_BLOCK_SIZE PMD_SIZE >> -#define SWAPPER_TABLE_SHIFT PUD_SHIFT >> -#else >> -#define SWAPPER_BLOCK_SHIFT PAGE_SHIFT >> -#define SWAPPER_BLOCK_SIZE PAGE_SIZE >> -#define SWAPPER_TABLE_SHIFT PMD_SHIFT >> -#endif > > Also a dangling comment here. These ? can be dropped off without much problem. /* Initial memory map size */ /* * Initial memory map attributes. */ Will try to re-arrange these comments next time around. - Anshuman > > Thanks, > Joey > >> >> /* >> * Initial memory map attributes. >> @@ -112,13 +108,6 @@ >> #define SWAPPER_PTE_FLAGS (PTE_TYPE_PAGE | PTE_AF | PTE_SHARED) >> #define SWAPPER_PMD_FLAGS (PMD_TYPE_SECT | PMD_SECT_AF | PMD_SECT_S) >> >> -#if ARM64_KERNEL_USES_PMD_MAPS >> -#define SWAPPER_RW_MMUFLAGS (PMD_ATTRINDX(MT_NORMAL) | SWAPPER_PMD_FLAGS) >> -#define SWAPPER_RX_MMUFLAGS (SWAPPER_RW_MMUFLAGS | PMD_SECT_RDONLY) >> -#else >> -#define SWAPPER_RW_MMUFLAGS (PTE_ATTRINDX(MT_NORMAL) | SWAPPER_PTE_FLAGS) >> -#define SWAPPER_RX_MMUFLAGS (SWAPPER_RW_MMUFLAGS | PTE_RDONLY) >> -#endif >> >> /* >> * To make optimal use of block mappings when laying out the linear >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c >> index 69deed27dec8..df1eac788c33 100644 >> --- a/arch/arm64/mm/mmu.c >> +++ b/arch/arm64/mm/mmu.c >> @@ -1192,7 +1192,7 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, >> >> WARN_ON((start < VMEMMAP_START) || (end > VMEMMAP_END)); >> >> - if (!ARM64_KERNEL_USES_PMD_MAPS) >> + if (!IS_ENABLED(CONFIG_ARM64_4K_PAGES)) >> return vmemmap_populate_basepages(start, end, node, altmap); >> >> do { _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel