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 08796C43334 for ; Mon, 4 Jul 2022 14:35:30 +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-Type: Content-Transfer-Encoding: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=smsseuDOPg32woFT/QLl5mjK1gM46kgGyLiNMQsQVCw=; b=lgLCcDqN4uetw4 1bflyy98fqJoNatsai3cRNPj8bRGPmO9/k6Mdh8YzeLlWW65ipCpUYjqNaC5gBf6iB4T3Z1Uu0vp0 KI6MXBnYQve8NRlZc872tk/fkomhG+92+r4O22mAD7Cy23cxxjqk5sK4c2HOWJwNsPRnCYctKVH/q k+EHQyuCfVQNqZte6JnXB2Nrq8QK9Im6Pli5OlqKEBvrAXQH2MGWk67nvGQUjObeDdWP65SPSC8BN EcXbB63QGDxVv9hQ5htL8lS2V/IgXeemomiGW+/wlR8eGSJ0h3BUWFL6bUPI9WIStgOK+JGit5yCZ kFAw1oBSiuoQRPv6J6pQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o8N9e-009Tg2-CH; Mon, 04 Jul 2022 14:34:26 +0000 Received: from out30-45.freemail.mail.aliyun.com ([115.124.30.45]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1o8N9a-009Tb7-EQ for linux-arm-kernel@lists.infradead.org; Mon, 04 Jul 2022 14:34:24 +0000 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R621e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04400;MF=guanghuifeng@linux.alibaba.com;NM=1;PH=DS;RN=21;SR=0;TI=SMTPD_---0VIO1tUl_1656945247; Received: from 30.225.28.131(mailfrom:guanghuifeng@linux.alibaba.com fp:SMTPD_---0VIO1tUl_1656945247) by smtp.aliyun-inc.com; Mon, 04 Jul 2022 22:34:09 +0800 Message-ID: <6977c692-78ca-5a67-773e-0389c85f2650@linux.alibaba.com> Date: Mon, 4 Jul 2022 22:34:07 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH v4] arm64: mm: fix linear mem mapping access performance degradation To: Will Deacon Cc: baolin.wang@linux.alibaba.com, catalin.marinas@arm.com, akpm@linux-foundation.org, david@redhat.com, jianyong.wu@arm.com, james.morse@arm.com, quic_qiancai@quicinc.com, christophe.leroy@csgroup.eu, jonathan@marek.ca, mark.rutland@arm.com, thunder.leizhen@huawei.com, anshuman.khandual@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, rppt@kernel.org, geert+renesas@glider.be, ardb@kernel.org, linux-mm@kvack.org, yaohongbo@linux.alibaba.com, alikernel-developer@linux.alibaba.com References: <1656777473-73887-1-git-send-email-guanghuifeng@linux.alibaba.com> <20220704103523.GC31437@willie-the-truck> <73f0c53b-fd17-c5e9-3773-1d71e564eb50@linux.alibaba.com> <20220704111402.GA31553@willie-the-truck> <4accaeda-572f-f72d-5067-2d0999e4d00a@linux.alibaba.com> <20220704131516.GC31684@willie-the-truck> <2ae1cae0-ee26-aa59-7ed9-231d67194dce@linux.alibaba.com> <20220704142313.GE31684@willie-the-truck> From: "guanghui.fgh" In-Reply-To: <20220704142313.GE31684@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220704_073423_204456_7BDAB60E X-CRM114-Status: GOOD ( 15.72 ) 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-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org VGhhbmtzLgoK5ZyoIDIwMjIvNy80IDIyOjIzLCBXaWxsIERlYWNvbiDlhpnpgZM6Cj4gT24gTW9u LCBKdWwgMDQsIDIwMjIgYXQgMTA6MTE6MjdQTSArMDgwMCwgZ3VhbmdodWkuZmdoIHdyb3RlOgo+ PiDlnKggMjAyMi83LzQgMjE6MTUsIFdpbGwgRGVhY29uIOWGmemBkzoKPj4+IE9uIE1vbiwgSnVs IDA0LCAyMDIyIGF0IDA4OjA1OjU5UE0gKzA4MDAsIGd1YW5naHVpLmZnaCB3cm90ZToKPj4+Pj4+ IDEuUXVvdGVkIG1lc3NhZ2VzIGZyb20gYXJjaC9hcm02NC9tbS9pbml0LmMKPj4+Pj4+Cj4+Pj4+ PiAiTWVtb3J5IHJlc2VydmF0aW9uIGZvciBjcmFzaCBrZXJuZWwgZWl0aGVyIGRvbmUgZWFybHkg b3IgZGVmZXJyZWQKPj4+Pj4+IGRlcGVuZGluZyBvbiBETUEgbWVtb3J5IHpvbmVzIGNvbmZpZ3Mg KFpPTkVfRE1BKSAtLQo+Pj4+Pj4KPj4+Pj4+IEluIGFic2VuY2Ugb2YgWk9ORV9ETUEgY29uZmln cyBhcm02NF9kbWFfcGh5c19saW1pdCBpbml0aWFsaXplZAo+Pj4+Pj4gaGVyZSBpbnN0ZWFkIG9m IG1heF96b25lX3BoeXMoKS4gIFRoaXMgbGV0cyBlYXJseSByZXNlcnZhdGlvbiBvZgo+Pj4+Pj4g Y3Jhc2gga2VybmVsIG1lbW9yeSB3aGljaCBoYXMgYSBkZXBlbmRlbmN5IG9uIGFybTY0X2RtYV9w aHlzX2xpbWl0Lgo+Pj4+Pj4gUmVzZXJ2aW5nIG1lbW9yeSBlYXJseSBmb3IgY3Jhc2gga2VybmVs IGFsbG93cyBsaW5lYXIgY3JlYXRpb24gb2YgYmxvY2sKPj4+Pj4+IG1hcHBpbmdzIChncmVhdGVy IHRoYW4gcGFnZS1ncmFudWxhcml0eSkgZm9yIGFsbCB0aGUgbWVtb3J5IGJhbmsgcmFuZ3MuCj4+ Pj4+PiBJbiB0aGlzIHNjaGVtZSBhIGNvbXBhcmF0aXZlbHkgcXVpY2tlciBib290IGlzIG9ic2Vy dmVkLgo+Pj4+Pj4KPj4+Pj4+IElmIFpPTkVfRE1BIGNvbmZpZ3MgYXJlIGRlZmluZWQsIGNyYXNo IGtlcm5lbCBtZW1vcnkgcmVzZXJ2YXRpb24KPj4+Pj4+IGlzIGRlbGF5ZWQgdW50aWwgRE1BIHpv bmUgbWVtb3J5IHJhbmdlIHNpemUgaW5pdGlhbGl6YXRpb24gcGVyZm9ybWVkIGluCj4+Pj4+PiB6 b25lX3NpemVzX2luaXQoKS4gIFRoZSBkZWZlciBpcyBuZWNlc3NhcnkgdG8gc3RlZXIgY2xlYXIg b2YgRE1BIHpvbmUKPj4+Pj4+IG1lbW9yeSByYW5nZSB0byBhdm9pZCBvdmVybGFwIGFsbG9jYXRp b24uCj4+Pj4+Pgo+Pj4+Pj4gW1tbCj4+Pj4+PiBTbyBjcmFzaCBrZXJuZWwgbWVtb3J5IGJvdW5k YXJpZXMgYXJlIG5vdCBrbm93biB3aGVuIG1hcHBpbmcgYWxsIGJhbmsgbWVtb3J5Cj4+Pj4+PiBy YW5nZXMsIHdoaWNoIG90aGVyd2lzZSBtZWFucyBub3QgcG9zc2libGUgdG8gZXhjbHVkZSBjcmFz aCBrZXJuZWwgcmFuZ2UKPj4+Pj4+IGZyb20gY3JlYXRpbmcgYmxvY2sgbWFwcGluZ3Mgc28gcGFn ZS1ncmFudWxhcml0eSBtYXBwaW5ncyBhcmUgY3JlYXRlZCBmb3IKPj4+Pj4+IHRoZSBlbnRpcmUg bWVtb3J5IHJhbmdlLgo+Pj4+Pj4gXV1dIgo+Pj4+Pj4KPj4+Pj4+IE5hbWVseSwgdGhlIGluaXQg b3JkZXI6IG1lbWJsb2NrIGluaXQtLS0+bGluZWFyIG1lbSBtYXBwaW5nKDRrIG1hcHBpbmcgZm9y Cj4+Pj4+PiBjcmFzaGtlcm5lbCwgcmVxdWlyaW5pZyBwYWdlLWdyYW51bGFyaXR5IGNoYW5naW5n KSktLS0+em9uZSBkbWEKPj4+Pj4+IGxpbWl0LS0tPnJlc2VydmUgY3Jhc2hrZXJuZWwuCj4+Pj4+ PiBTbyB3aGVuIGVuYWJsZSBaT05FIERNQSBhbmQgdXNpbmcgY3Jhc2hrZXJuZWwsIHRoZSBtZW0g bWFwcGluZyB1c2luZyA0awo+Pj4+Pj4gbWFwcGluZy4KPj4+Pj4KPj4+Pj4gWWVzLCBJIHVuZGVy c3RhbmQgdGhhdCBpcyBob3cgdGhpbmdzIHdvcmsgdG9kYXkgYnV0IEknbSBzYXlpbmcgdGhhdCB3 ZSBtYXkKPj4+Pj4gYXMgd2VsbCBsZWF2ZSB0aGUgY3Jhc2hrZXJuZWwgbWFwcGVkIChhdCBibG9j ayBncmFudWxhcml0eSkgaWYKPj4+Pj4gIWNhbl9zZXRfZGlyZWN0X21hcCgpIGFuZCB0aGVuIEkg dGhpbmsgeW91ciBwYXRjaCBiZWNvbWVzIGEgbG90IHNpbXBsZXIuCj4+Pj4KPj4+PiBCdXQgUGFn ZS1ncmFudWxhcml0eSBtYXBwcGluZ3MgYXJlIG5lY2Vzc2FyeSBmb3IgY3Jhc2gga2VybmVsIG1l bW9yeSByYW5nZQo+Pj4+IGZvciBzaHJpbmtpbmcgaXRzIHNpemUgdmlhIC9zeXMva2VybmVsL2tl eGVjX2NyYXNoX3NpemUgaW50ZXJmYWMoUXVvdGVkIGZyb20KPj4+PiBhcmNoL2FybTY0L21tL2lu aXQuYykuCj4+Pj4gU28gdGhpcyBwYXRjaCBzcGxpdCBibG9jay9zZWN0aW9uIG1hcHBpbmcgdG8g NGsgcGFnZS1ncmFudWxhcml0eSBtYXBwaW5nIGZvcgo+Pj4+IGNyYXNoa2VybmVsIG1lbS4KPj4+ Cj4+PiBXaHk/IEkgZG9uJ3Qgc2VlIHdoeSB0aGUgbWFwcGluZyBncmFudWxhcml0eSBpcyByZWxl dmFudCBhdCBhbGwgaWYgd2UKPj4+IGFsd2F5cyBsZWF2ZSB0aGUgd2hvbGUgdGhpbmcgbWFwcGVk Lgo+Pj4KPj4gVGhlcmUgaXMgYW5vdGhlciByZWFzb24uCj4+Cj4+IFdoZW4gbG9hZGluZyBjcmFz aGtlcm5lbCBmaW5pc2gsIHRoZSBkb19rZXhlY19sb2FkIHdpbGwgdXNlCj4+IGFyY2hfa2V4ZWNf cHJvdGVjdF9jcmFzaGtyZXMgdG8gaW52YWxpZCBhbGwgdGhlIHBhZ2V0YWJsZSBmb3IgY3Jhc2hr ZXJuZWwKPj4gbWVtKHByb3RlY3QgY3Jhc2hrZXJuZWwgbWVtIGZyb20gYWNjZXNzKS4KPj4KPj4g YXJjaF9rZXhlY19wcm90ZWN0X2NyYXNoa3Jlcy0tLT5zZXRfbWVtb3J5X3ZhbGlkLS0tPi4uLi0t LT5hcHBseV90b19wbWRfcmFuZ2UKPj4KPj4gSW4gdGhlIGFwcGx5X3RvX3BtZF9yYW5nZSwgdGhl cmUgaXMgYSBqdWRlbWVudO+8miBCVUdfT04ocHVkX2h1Z2UoKnB1ZCkpLiBBbmQKPj4gaWYgdGhl IGNyYXNoa2VybmVsIHVzZSBibG9jay9zZWN0aW9uIG1hcHBpbmcsIHRoZXJlIHdpbGwgYmUgc29t ZSBlcnJvci4KPj4KPj4gTmFtZWx5LCBpdCdzIG5lZWQgdG8gdXNlIG5vbiBibG9jay9zZWN0aW9u IG1hcHBpbmcgZm9yIGNyYXNoa2VybmVsIG1lbQo+PiBiZWZvcmUgc2hyaW5na2luZy4KPiAKPiBX ZWxsLCB5ZXMsIGJ1dCB3ZSBjYW4gY2hhbmdlIGFyY2hfa2V4ZWNfW3VuXXByb3RlY3RfY3Jhc2hr cmVzKCkgbm90IHRvIGRvCj4gdGhhdCBpZiB3ZSdyZSBsZWF2aW5nIHRoZSB0aGluZyBtYXBwZWQs IG5vPwo+IAo+IFdpbGwKCkkgdGhpbmsgd2Ugc2hvdWxkIHVzZSBhcmNoX2tleGVjX1t1bl1wcm90 ZWN0X2NyYXNoa3JlcyBmb3IgY3Jhc2hrZXJuZWwgbWVtLgoKQmVjYXVzZSB3aGVuIGludmFsaWQg Y3Jhc2hrZXJuZWwgbWVtIHBhZ2V0YWJsZSwgdGhlcmUgaXMgbm8gY2hhbmNlIHRvIApyZC93ciB0 aGUgY3Jhc2hrZXJuZWwgbWVtIGJ5IG1pc3Rha2UuCgpJZiB3ZSBkb24ndCB1c2UgYXJjaF9rZXhl Y19bdW5dcHJvdGVjdF9jcmFzaGtyZXMgdG8gaW52YWxpZCBjcmFzaGtlcm5lbCAKbWVtIHBhZ2V0 YWJsZSwgdGhlcmUgbWF5YmUgc29tZSB3cml0ZSBvcGVyYXRpb25zIHRvIHRoZXNlIG1lbSBieSBt aXN0YWtlIAp3aGljaCBtYXkgY2F1c2UgY3Jhc2hrZXJuZWwgYm9vdCBlcnJvciBhbmQgdm1jb3Jl IHNhdmluZyBlcnJvci4KCkNhbiB3ZSBjaGFuZ2UgdGhlIGFyY2hfa2V4ZWNfW3VuXXByb3RlY3Rf Y3Jhc2hrcmVzIHRvIHN1cHBvcnQgCmJsb2NrL3NlY3Rpb24gbWFwcGluZz8oQnV0IHdlIGFsc28g bmVlZCB0byByZW1hcCB3aGVuIHNocmlua2luZykKClRoYW5rcy4KCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBs aXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5m cmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK 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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 23774C43334 for ; Mon, 4 Jul 2022 14:34:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9E3266B0073; Mon, 4 Jul 2022 10:34:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 993106B0074; Mon, 4 Jul 2022 10:34:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 882AD6B0075; Mon, 4 Jul 2022 10:34:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 7C8726B0073 for ; Mon, 4 Jul 2022 10:34:16 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 5C23A6043F for ; Mon, 4 Jul 2022 14:34:16 +0000 (UTC) X-FDA: 79649662512.26.2F647FE Received: from out30-56.freemail.mail.aliyun.com (out30-56.freemail.mail.aliyun.com [115.124.30.56]) by imf08.hostedemail.com (Postfix) with ESMTP id 954CF160044 for ; Mon, 4 Jul 2022 14:34:14 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R621e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04400;MF=guanghuifeng@linux.alibaba.com;NM=1;PH=DS;RN=21;SR=0;TI=SMTPD_---0VIO1tUl_1656945247; Received: from 30.225.28.131(mailfrom:guanghuifeng@linux.alibaba.com fp:SMTPD_---0VIO1tUl_1656945247) by smtp.aliyun-inc.com; Mon, 04 Jul 2022 22:34:09 +0800 Message-ID: <6977c692-78ca-5a67-773e-0389c85f2650@linux.alibaba.com> Date: Mon, 4 Jul 2022 22:34:07 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH v4] arm64: mm: fix linear mem mapping access performance degradation To: Will Deacon Cc: baolin.wang@linux.alibaba.com, catalin.marinas@arm.com, akpm@linux-foundation.org, david@redhat.com, jianyong.wu@arm.com, james.morse@arm.com, quic_qiancai@quicinc.com, christophe.leroy@csgroup.eu, jonathan@marek.ca, mark.rutland@arm.com, thunder.leizhen@huawei.com, anshuman.khandual@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, rppt@kernel.org, geert+renesas@glider.be, ardb@kernel.org, linux-mm@kvack.org, yaohongbo@linux.alibaba.com, alikernel-developer@linux.alibaba.com References: <1656777473-73887-1-git-send-email-guanghuifeng@linux.alibaba.com> <20220704103523.GC31437@willie-the-truck> <73f0c53b-fd17-c5e9-3773-1d71e564eb50@linux.alibaba.com> <20220704111402.GA31553@willie-the-truck> <4accaeda-572f-f72d-5067-2d0999e4d00a@linux.alibaba.com> <20220704131516.GC31684@willie-the-truck> <2ae1cae0-ee26-aa59-7ed9-231d67194dce@linux.alibaba.com> <20220704142313.GE31684@willie-the-truck> From: "guanghui.fgh" In-Reply-To: <20220704142313.GE31684@willie-the-truck> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656945256; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OWVBB6sgrOV/xLBm43nWckWaiQE2JkRvB6Ze2uZl2VI=; b=lXuiFehqucomI3OXvW7IXuXv/w8c1TcWn24U1gKpFDlgPOgmspOTL15FEaP4A7BUP7Ha7z eCVG2LAtRiXY4RcDMRR93UzZYhGd/1o5y8xN+Y/+vuq1Xf5xtSPrKkOTIXY+pOAzHthDVO y6ngKQVKYdRKI3ZAfd4laLu5DN8GtE0= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=alibaba.com; spf=pass (imf08.hostedemail.com: domain of guanghuifeng@linux.alibaba.com designates 115.124.30.56 as permitted sender) smtp.mailfrom=guanghuifeng@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656945256; a=rsa-sha256; cv=none; b=kFv/Pwz+8zTPRr0O+cMJxMA6Su+pUqktDZGvb/mZJO8AkYt/da7XHhw8+lGzRCXHqk4NJK BOuDg7QDME5ukb6NIxIkDTZSTk1pR417/CINvsqmd9l8BMnMgHIzlsnUdWVKyQ8Weu4cqQ fk/A+NOQtaa8FIGg9rBFnWkuLbp3lMs= X-Rspam-User: X-Rspamd-Queue-Id: 954CF160044 Authentication-Results: imf08.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=alibaba.com; spf=pass (imf08.hostedemail.com: domain of guanghuifeng@linux.alibaba.com designates 115.124.30.56 as permitted sender) smtp.mailfrom=guanghuifeng@linux.alibaba.com X-Stat-Signature: y97asum8tck5ccmy8c3doxtunsa3zq7i X-Rspamd-Server: rspam08 X-HE-Tag: 1656945254-965740 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: Thanks. 在 2022/7/4 22:23, Will Deacon 写道: > On Mon, Jul 04, 2022 at 10:11:27PM +0800, guanghui.fgh wrote: >> 在 2022/7/4 21:15, Will Deacon 写道: >>> On Mon, Jul 04, 2022 at 08:05:59PM +0800, guanghui.fgh wrote: >>>>>> 1.Quoted messages from arch/arm64/mm/init.c >>>>>> >>>>>> "Memory reservation for crash kernel either done early or deferred >>>>>> depending on DMA memory zones configs (ZONE_DMA) -- >>>>>> >>>>>> In absence of ZONE_DMA configs arm64_dma_phys_limit initialized >>>>>> here instead of max_zone_phys(). This lets early reservation of >>>>>> crash kernel memory which has a dependency on arm64_dma_phys_limit. >>>>>> Reserving memory early for crash kernel allows linear creation of block >>>>>> mappings (greater than page-granularity) for all the memory bank rangs. >>>>>> In this scheme a comparatively quicker boot is observed. >>>>>> >>>>>> If ZONE_DMA configs are defined, crash kernel memory reservation >>>>>> is delayed until DMA zone memory range size initialization performed in >>>>>> zone_sizes_init(). The defer is necessary to steer clear of DMA zone >>>>>> memory range to avoid overlap allocation. >>>>>> >>>>>> [[[ >>>>>> So crash kernel memory boundaries are not known when mapping all bank memory >>>>>> ranges, which otherwise means not possible to exclude crash kernel range >>>>>> from creating block mappings so page-granularity mappings are created for >>>>>> the entire memory range. >>>>>> ]]]" >>>>>> >>>>>> Namely, the init order: memblock init--->linear mem mapping(4k mapping for >>>>>> crashkernel, requirinig page-granularity changing))--->zone dma >>>>>> limit--->reserve crashkernel. >>>>>> So when enable ZONE DMA and using crashkernel, the mem mapping using 4k >>>>>> mapping. >>>>> >>>>> Yes, I understand that is how things work today but I'm saying that we may >>>>> as well leave the crashkernel mapped (at block granularity) if >>>>> !can_set_direct_map() and then I think your patch becomes a lot simpler. >>>> >>>> But Page-granularity mapppings are necessary for crash kernel memory range >>>> for shrinking its size via /sys/kernel/kexec_crash_size interfac(Quoted from >>>> arch/arm64/mm/init.c). >>>> So this patch split block/section mapping to 4k page-granularity mapping for >>>> crashkernel mem. >>> >>> Why? I don't see why the mapping granularity is relevant at all if we >>> always leave the whole thing mapped. >>> >> There is another reason. >> >> When loading crashkernel finish, the do_kexec_load will use >> arch_kexec_protect_crashkres to invalid all the pagetable for crashkernel >> mem(protect crashkernel mem from access). >> >> arch_kexec_protect_crashkres--->set_memory_valid--->...--->apply_to_pmd_range >> >> In the apply_to_pmd_range, there is a judement： BUG_ON(pud_huge(*pud)). And >> if the crashkernel use block/section mapping, there will be some error. >> >> Namely, it's need to use non block/section mapping for crashkernel mem >> before shringking. > > Well, yes, but we can change arch_kexec_[un]protect_crashkres() not to do > that if we're leaving the thing mapped, no? > > Will I think we should use arch_kexec_[un]protect_crashkres for crashkernel mem. Because when invalid crashkernel mem pagetable, there is no chance to rd/wr the crashkernel mem by mistake. If we don't use arch_kexec_[un]protect_crashkres to invalid crashkernel mem pagetable, there maybe some write operations to these mem by mistake which may cause crashkernel boot error and vmcore saving error. Can we change the arch_kexec_[un]protect_crashkres to support block/section mapping?(But we also need to remap when shrinking) Thanks.