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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 22C2CC433EF for ; Fri, 12 Nov 2021 09:45:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B8D9460F22 for ; Fri, 12 Nov 2021 09:45:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B8D9460F22 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 42AF56B0074; Fri, 12 Nov 2021 04:45:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3B4716B0078; Fri, 12 Nov 2021 04:45:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2550B6B007B; Fri, 12 Nov 2021 04:45:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0094.hostedemail.com [216.40.44.94]) by kanga.kvack.org (Postfix) with ESMTP id 1179C6B0074 for ; Fri, 12 Nov 2021 04:45:25 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id BA8EA76BAE for ; Fri, 12 Nov 2021 09:45:24 +0000 (UTC) X-FDA: 78799795368.25.DEDA660 Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by imf17.hostedemail.com (Postfix) with ESMTP id 5D283F0003B5 for ; Fri, 12 Nov 2021 09:45:24 +0000 (UTC) Received: by mail-qt1-f169.google.com with SMTP id a2so7851922qtx.11 for ; Fri, 12 Nov 2021 01:45:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cTQbLu7DJzgYczzeDokbBx6jczd3POR7HqpLSqJtY74=; b=p9Aqslkb2a+UcbKwRGO9FEp4C3WiqewziLqsYJypQBlOjGAxccgxaSumry40GN7WuN Z/c7hx6i6HUUKaX8ioEKldnVVdVcQ3Au84D6WPiJCcJeci9bqKQiUgKLr6wl7Sz7XpJR tTcarZf9bsfVFeAmb6Jprh9mpL/mg6tz59hRsVIxmMuaduOera0rdggPQI67eS9Ouk02 oVJHuwSEd0H0P+rZVjRVWt315YH5dA2FHX1i7xlyErtIOzgq2bCC8IhJmuzx/wskXD6u 28vvhIGdV/esnZPBuHW6d/2d9A01Pm7InNnOhyjYqIaRsqQ95E3empNoWjeSJy1nKGfq 4A5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cTQbLu7DJzgYczzeDokbBx6jczd3POR7HqpLSqJtY74=; b=pshg2UzNyivAOQ33qWBi8y2Jv13LGqsNhXDkubBVl4hdoqKsAXrCe1CWkrA3iJdjcm yI/IUoVvkCDVbEoYgJ0w5pSQ1VTZA3plg37LV8XHEyAsSe3Q4ScN0huwnVevBVGxYzA1 aUC+tWg9NLkirz+R5F8Sh+tTeI7bSciqgKhucZKqF2qJvT+/XjNpzZCl1/nwSHPyKFbr gizc7WIWeXhnsbt6E4oSiv9aayI8tkb4OF0RIKz9jRk1r4A3DYnOkOmJ7+Bt/SgY+KI7 vSZBZtouGxIhgBitgvzkGHqXjNsLmWkptSIKnmhdSxr6mkoZek/ohpPQT6utYHSxfATy wXyg== X-Gm-Message-State: AOAM533l2h+YnfjKgnTcv9BSYIYphQAk2oJB3AB+MP+AIyY65KJZuXgs UKb0ttvHtnbzI8E4HzZZScVc3cqS1wAoxZ47vDA= X-Google-Smtp-Source: ABdhPJxDGLbzpvUml615volfmkjIGGCrVkrAChYxV/OvhAnhgiObEE1hRGpZcJqyNBGRh4B9bPLoYW2qQwlIzkInngI= X-Received: by 2002:ac8:580b:: with SMTP id g11mr14442034qtg.272.1636710323681; Fri, 12 Nov 2021 01:45:23 -0800 (PST) MIME-Version: 1.0 References: <1636708842-25787-1-git-send-email-huangzhaoyang@gmail.com> In-Reply-To: From: Zhaoyang Huang Date: Fri, 12 Nov 2021 17:45:02 +0800 Message-ID: Subject: Re: [RFC PATCH] arch: arm64: have memblocks out of kernel text use section map To: Ard Biesheuvel Cc: Catalin Marinas , Will Deacon , Anshuman Khandual , Andrew Morton , Nicholas Piggin , Mike Rapoport , Pavel Tatashin , Christophe Leroy , Jonathan Marek , Zhaoyang Huang , Linux Memory Management List , Linux Kernel Mailing List , ben.dai@unisoc.com, lvqiang.huang@unisoc.com, Ke Wang Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 5D283F0003B5 X-Stat-Signature: 3tue9u7nfaqd36g17mwyijir5eqa1rtr Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=p9Aqslkb; spf=pass (imf17.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1636710324-439699 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Nov 12, 2021 at 5:31 PM Ard Biesheuvel wrote: > > On Fri, 12 Nov 2021 at 10:21, Huangzhaoyang wrote: > > > > From: Zhaoyang Huang > > > > By comparing the swapper_pg_dir with k54 > > I take it this means Linux v5.4 ? > > > and previous versions,we find > > that the linear mappings within which the addr is out of kernel text section > > will use the smallest pte. It should arise for the sake of rodata_full, which > > set all memblock use NO_CONT_MAPPINGS. > > > > OK so your intent seems to be to use block mappings for the linear > alias of the kernel text and rodata, right? > > What does that achieve? It should make no difference in TLB pressure, > as the linear alias is rarely referenced (we only kept it around for > hibernate). So I guess we save a handful of pages for page tables. Thanks for the quick response and sorry for causing confusion with my poor comments. What I want to do is on the contrary, that is using block mapping on the addr OUT OF the kernel text, which could be affected by setting rodata_full(can_set_direct_map) so far. > > > Signed-off-by: Zhaoyang Huang > > --- > > arch/arm64/mm/mmu.c | 11 ++++++++++- > > 1 file changed, 10 insertions(+), 1 deletion(-) > > > > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c > > index cfd9deb..14e1bea 100644 > > --- a/arch/arm64/mm/mmu.c > > +++ b/arch/arm64/mm/mmu.c > > @@ -252,6 +252,8 @@ static void init_pmd(pud_t *pudp, unsigned long addr, unsigned long end, > > pmd_clear_fixmap(); > > } > > > > +static bool crash_mem_map __initdata; > > + > > static void alloc_init_cont_pmd(pud_t *pudp, unsigned long addr, > > unsigned long end, phys_addr_t phys, > > pgprot_t prot, > > @@ -259,7 +261,15 @@ static void alloc_init_cont_pmd(pud_t *pudp, unsigned long addr, > > { > > unsigned long next; > > pud_t pud = READ_ONCE(*pudp); > > + unsigned long len = end - addr; > > + phys_addr_t kernel_start = __pa_symbol(_stext); > > + phys_addr_t kernel_end = __pa_symbol(__init_begin); > > > > + if (debug_pagealloc_enabled() || crash_mem_map || IS_ENABLED(CONFIG_KFENCE)) > > + ; > > + else if (phys > kernel_end || phys + len < kernel_start) { > > + flags &= ~(NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS); > > + } > > Please don't use empty statements like this, and I'm not sure we even > need this check: I wouldn't expect debug_pagealloc or KFENCE to ever > require page granular mappings of this region either. > > Also, please add a comment to explain what the condition is meant to > check (i..e, that the PMD entry covers a part of the linear alias of > the kernel image, and so there is no need to map it down to pages or > to avoid contiguous mappings) > > > /* > > * Check for initial section mappings in the pgd/pud. > > */ > > @@ -483,7 +493,6 @@ void __init mark_linear_text_alias_ro(void) > > PAGE_KERNEL_RO); > > } > > > > -static bool crash_mem_map __initdata; > > > > static int __init enable_crash_mem_map(char *arg) > > { > > -- > > 1.9.1 > >