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 DEE9AC433EF for ; Fri, 8 Jul 2022 12:29:29 +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=/ROCkQangS5G8oqRW2GGE1K534uzTpQbyvJtjxo1oFU=; b=plUUMN2pBWEgtG C0pn6tmMnlw5mxzLanTUYxERGOMT8ZYr67bqCcGG/uDYMKfW+FrPtzDEXjcqZFC8bwguaIX8aRUIk W86neJ8Lj+I9sbgo8FCHdBcwpWRpZISt7/n3M3vwFFxWiUIO2skSDPZs6wk495AtNmgjaOeL5d6OM W+ppTdKxpSdXePxO8QRI4DcN2/I6Ka08qJkjX+4cwfcRn7cPMkR0eppxfRkTMTHNGjITGqdG08o/H t2sVbRy0tyi5zLinMg+m87ptRG49thQJuKSF+F7Ai0PJPBKkL1Q6Il1VjhK/wIK9SzCwT2vboTx+O qLyDYzCLXYk2AayhIxwA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o9n5w-003iyY-Le; Fri, 08 Jul 2022 12:28:28 +0000 Received: from out30-56.freemail.mail.aliyun.com ([115.124.30.56]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1o9n5t-003ixS-1W for linux-arm-kernel@lists.infradead.org; Fri, 08 Jul 2022 12:28:27 +0000 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R161e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045170;MF=guanghuifeng@linux.alibaba.com;NM=1;PH=DS;RN=21;SR=0;TI=SMTPD_---0VIjXe4a_1657283299; Received: from 30.225.28.127(mailfrom:guanghuifeng@linux.alibaba.com fp:SMTPD_---0VIjXe4a_1657283299) by smtp.aliyun-inc.com; Fri, 08 Jul 2022 20:28:20 +0800 Message-ID: Date: Fri, 8 Jul 2022 20:28:18 +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 RESEND v4] arm64: mm: fix linear mem mapping access performance degradation To: Catalin Marinas Cc: Mike Rapoport , Will Deacon , Ard Biesheuvel , baolin.wang@linux.alibaba.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, geert+renesas@glider.be, linux-mm@kvack.org, yaohongbo@linux.alibaba.com, alikernel-developer@linux.alibaba.com References: <5d044fdd-a61a-d60f-d294-89e17de37712@linux.alibaba.com> <20220705121115.GB1012@willie-the-truck> <9974bea5-4db9-0104-c9c9-d9b49c390f1b@linux.alibaba.com> From: "guanghui.fgh" In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220708_052825_299162_D7C258D4 X-CRM114-Status: GOOD ( 19.70 ) 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 VGhhbmtzLgoK5ZyoIDIwMjIvNy82IDIzOjQwLCBDYXRhbGluIE1hcmluYXMg5YaZ6YGTOgo+IE9u IFdlZCwgSnVsIDA2LCAyMDIyIGF0IDExOjE4OjIyUE0gKzA4MDAsIGd1YW5naHVpLmZnaCB3cm90 ZToKPj4g5ZyoIDIwMjIvNy82IDIxOjU0LCBNaWtlIFJhcG9wb3J0IOWGmemBkzoKPj4+IE9uZSB0 aGluZyBJIGNhbiB0aGluayBvZiBpcyB0byBvbmx5IHJlbWFwIHRoZSBjcmFzaCBrZXJuZWwgbWVt b3J5IGlmIGl0IGlzCj4+PiBhIHBhcnQgb2YgYW4gYWxsb2NhdGlvbiB0aGF0IGV4YWN0bHkgZml0 cyBpbnRvIG9uZSBvcmUgbW9yZSBQVURzLgo+Pj4KPj4+IFNheSwgaW4gcmVzZXJ2ZV9jcmFzaGtl cm5lbCgpIHdlIHRyeSB0aGUgbWVtYmxvY2tfcGh5c19hbGxvYygpIHdpdGgKPj4+IFBVRF9TSVpF IGFzIGFsaWdubWVudCBhbmQgc2l6ZSByb3VuZGVkIHVwIHRvIFBVRF9TSVpFLiBJZiB0aGlzIGFs bG9jYXRpb24KPj4+IHN1Y2NlZWRzLCB3ZSByZW1hcCB0aGUgZW50aXJlIGFyZWEgdGhhdCBub3cg Y29udGFpbnMgb25seSBtZW1vcnkgYWxsb2NhdGVkCj4+PiBpbiByZXNlcnZlX2NyYXNoa2VybmVs KCkgYW5kIGZyZWUgdGhlIGV4dHJhIG1lbW9yeSBhZnRlciByZW1hcHBpbmcgaXMgZG9uZS4KPj4+ IElmIHRoZSBsYXJnZSBhbGxvY2F0aW9uIGZhaWxzLCB3ZSBmYWxsIGJhY2sgdG8gdGhlIG9yaWdp bmFsIHNpemUgYW5kCj4+PiBhbGlnbm1lbnQgYW5kIGRvbid0IGFsbG93IHVubWFwcGluZyBjcmFz aCBrZXJuZWwgbWVtb3J5IGluCj4+PiBhcmNoX2tleGVjX3Byb3RlY3RfY3Jhc2hrcmVzKCkuCj4+ Cj4+IFRoZXJlIGlzIGEgbmV3IG1ldGhvZC4KPj4gSSB0aGluayB3ZSBzaG91bGQgdXNlIHRoZSBw YXRjaCB2MyhzaW1pbGFyIGJ1dCBuZWVkIGFkZCBzb21lIGNoYW5nZXMpCj4+Cj4+IDEuV2UgY2Fu IHdhbGsgY3Jhc2hrZXJubGUgYmxvY2svc2VjdGlvbiBwYWdldGFibGUsCj4+IFtbWyhrZWVwIHRo ZSBvcmlnaW4gYmxvY2svc2VjdGlvbiBtYXBwaW5nIHZhbGlkXV1dCj4+IHJlYnVpbGQgdGhlIHB0 ZSBsZXZlbCBwYWdlIG1hcHBpbmcgZm9yIHRoZSBjcmFzaGtlcm5lbCBtZW0KPj4gcmVidWlsZCBs ZWZ0ICYgcmlnaHQgbWFyZ2luIG1lbSh3aGljaCBpcyBpbiBzYW1lIGJsb2NrL3NlY3Rpb24gbWFw cGluZyBidXQKPj4gb3V0IG9mIGNyYXNoa2VybmVsIG1lbSkgd2l0aCBibG9jay9zZWN0aW9uIG1h cHBpbmcKPj4KPj4gMi4ncmVwbGFjZScgdGhlIG9yaWdpbiBibG9jay9zZWN0aW9uIG1hcHBpbmcg YnkgbmV3IGJ1aWxkZWQgbWFwcGluZwo+PiBpdGVyYXRlbHkKPj4KPj4gV2l0aCB0aGlzIG1ldGhv ZCwgYWxsIHRoZSBtZW0gbWFwcGluZyBrZWVwIHZhbGlkIGFsbCB0aGUgdGltZS4KPiAKPiBBcyBJ IGFscmVhZHkgY29tbWVudGVkIG9uIG9uZSBvZiB5b3VyIHByZXZpb3VzIHBhdGNoZXMsIHRoaXMg aXMgbm90Cj4gYWxsb3dlZCBieSB0aGUgYXJjaGl0ZWN0dXJlLiBJZiBGRUFUX0JCTSBpcyBpbXBs ZW1lbnRlZCAoQVJNdjguNCBJCj4gdGhpbmspLCB0aGUgd29yc3QgdGhhdCBjYW4gaGFwcGVuIGlz IGEgVExCIGNvbmZsaWN0IGFib3J0IGFuZCB0aGUKPiBoYW5kbGVyIHNob3VsZCBpbnZhbGlkYXRl IHRoZSBUTEJzIGFuZCByZXN0YXJ0IHRoZSBmYXVsdGluZyBpbnN0cnVjdGlvbiwKPiBhc3N1bWlu ZyB0aGUgaGFuZGxlciB3b24ndCB0cnkgdG8gYWNjZXNzIHRoZSBzYW1lIGNvbmZsaWN0aW5nIHZp cnR1YWwKPiBhZGRyZXNzLiBQcmlvciB0byBGRUFUX0JCTSwgdGhhdCdzIG5vdCBwb3NzaWJsZSBh cyB0aGUgYXJjaGl0ZWN0dXJlIGRvZXMKPiBub3QgZGVzY3JpYmUgYSBwcmVjaXNlIGJlaGF2aW91 ciBvZiBjb25mbGljdGluZyBUTEIgZW50cmllcyAoeW91IG1pZ2h0Cj4gYXMgd2VsbCBnZXQgdGhl IFRMQiBvdXRwdXQgb2YgbXVsdGlwbGUgZW50cmllcyBiZWluZyBvcidlZCB0b2dldGhlcikuCj4g CgpUaGUgY3B1IGNhbiBnZW5lcmF0ZSBhIFRMQiBjb25mbGljdCBhYm9ydCBpZiBpdCBkZXRlY3Rz IHRoYXQgdGhlIGFkZHJlc3MgCmJlaW5nIGxvb2tlZCB1cCBpbiB0aGUgVExCIGhpdHMgbXVsdGlw bGUgZW50cmllcy4KCigxKS5JIHRoaW5rIHdoZW4gZ2F0aGVyaW5nIHNtYWxsIHBhZ2UgdG8gYmxv Y2svc2VjdGlvbiBtYXBwaW5nLCB0aGVyZSAKbWF5YmUgdGxiIGNvbmZsaWN0IGlmIG5vIGNvbXBs eWluZyB3aXRoIEJCTS4KCk5hbWVseToKYS5NYXAgYSA0S0IgcGFnZSAoYWRkcmVzcyBYKQogICBU b3VjaCB0aGF0IHBhZ2UsIGluIG9yZGVyIHRvIGdldCB0aGUgdHJhbnNsYXRpb24gY2FjaGVkIGlu IHRoZSBUTEIKCmIuTW9kaWZ5IHRoZSB0cmFuc2xhdGlvbiB0YWJsZXMKICAgcmVwbGFjaW5nIHRo ZSBtYXBwaW5nIGZvciBhZGRyZXNzIFggd2l0aCBhIDJNQiBtYXBwaW5nIC0gRE8gTk9UIApJTlZB TElEQVRFIHRoZSBUTEIKCmMuVG91Y2ggIlggKyA0S0IiCiAgIFRoaXMgd2lsbC9zaG91bGQgbWlz cyBpbiB0aGUgVExCLCBjYXVzaW5nIGEgbmV3IHdhbGsgcmV0dXJuaW5nIHRoZSAKMk1CIG1hcHBp bmcKCmQuVG91Y2ggWAogICBBc3N1bWluZyB0aGV5J3ZlIG5vdCBiZWVuIGV2aWN0ZWQsIHlvdSds bCBoaXQgYm90aCBvbiB0aGUgNEtCIGFuZCAyTUIgCm1hcHBpbmcgLSBhcyBib3RoIGNvdmVyIGFk ZHJlc3MgWC4KClRoZXJlIGlzIHRsYiBjb25mbGljdC4KKGxpbms6IApodHRwczovL2NvbW11bml0 eS5hcm0uY29tL3N1cHBvcnQtZm9ydW1zL2YvZGV2LXBsYXRmb3Jtcy1mb3J1bS8xMzU4My90bGIt Y29uZmxpY3QtYWJvcnQpCgoKCigyKS5CdXQgd2hlbiBzcGxpdGluZyBsYXJnZSBibG9jay9zZWN0 aW9uIG1hcHBpbmcgdG8gc21hbGwgZ3JhbnVsYXJpdHksIAp0aGVyZSBtYXliZSBubyB0bGIgY29u ZmxpY3QuCgpOYW1lbHk6CmEucmVidWlsZCB0aGUgcHRlIGxldmVsIG1hcHBpbmcgd2l0aG91dCBh bnkgY2hhbmdlIHRvIG9yZ2luIHBhZ2V0YWJsZQogICAodGhlIHJlbGF0aW9uIGJldHdlZW4gdmly dHVhbCBhZGRyZXNzIGFuZCBwaHlzaWNhbGwgYWRkcmVzcyBrZWVwIHNhbWUpCgpiLm1vZGlmeSAx RyBtYXBwdGluZyB0byB1c2UgdGhlIG5ldyBwdGUgbGV2ZWwgbWFwcGluZyBpbiB0aGUgW1tbbWVt XV1dIAp3aXRob3V0IHRsYiBmbHVzaAoKYy5XaGVuIHRoZSBjcHUgYWNjZXNzIHRoZSAxRyBtZW0o YW55d2hlcmUpLAogICBJZiAxRyB0bGIgZW50cnkgYWxyZWFkeSBjYWNoZWQgaW4gdGxiLCBhbGwg dGhlIDFHIG1lbSB3aWxsIGFjY2VzcyAKc3VjY2Vzcyh3aXRob3V0IGFueSB0bGIgbG9hZGVkLCBu byBjb25maWxpY3QpCgogICBJZiAxRyB0bGIgZW50cnkgaGFzIGJlZW4gZXZpY3RlZCwgdGhlbiB0 aGUgdGxiIHdpbGwgYWNjZXNzIHBhZ2V0YWJsZSAKaW4gbWVtKGRlc3BpdGUgdGhlIGNwdSAiY2F0 Y2giIHRoZSBvbGQoMUcpIG9yIG5ldyg0aykgbWFwcGVkIHBhZ2V0YWxlIGluIAp0aGUgbWVtLCBh bGwgdGhlIDFHIG1lbSBjYW4gYWNjZXNzIHN1Y2VzcykobG9hZCBuZXcgdGxiIGVudHJ5LCBubyBj b25mbGljdCkKCmQuQWZ0ZXJ3YXJkLCB3ZSBmbHVzaCB0aGUgdGxiIGFuZCBmb3JjZSBjcHUgdXNl IHRoZSBuZXcgcGFnZXRhYmxlLihubyAKY29uZmxpY3QpCgpJdCBzZWVtcyB0aGF0IHRoZXJlIGFy ZSBubyB0d28gdGxiIGVudHJpZXMgZm9yIGEgc2FtZSB2aXJ0dWFsIGFkZHJlc3MgaW4gCnRoZSB0 bGIgY2FjaGUgV2hlbiBzcGxpdGluZyBsYXJnZSBibG9jay9zZWN0aW9uIG1hcHBpbmcuCgoKCigz KS5BdCB0aGUgc2FtZSB0aW1lLCBJIHRoaW5rIHdlIGNhbiB1c2UgYW5vdGhlciB3YXkuCkFzIHRo ZSBzeXN0ZW0gbGluZWFyIG1hcGluZyBpcyBidWlsZGVkIHdpdGggaW5pdF9wZ19kaXIsIHdlIGNh biBhbHNvIApyZXN1ZSB0aGUgaW5pdF9wZ19kaXIgdG8gc3BsaXQgdGhlIGJsb2NrL3NldGlvbiBt YXBwaW5nIHNvbWV0aW1lLgpBcyBpbml0X3BnX2RpciBjb250YWluIGFsbCBrZXJuZWwgdGV4dC9k YXRhIGFjY2VzcyBhbmQgd2UgY2FuIGNvbXBseSAKd2l0aCB0aGUgQkJNIHJlcXVpcmVtZW50LgoK YS5yZWJ1aWxkIG5ldyBwdGUgbGV2ZWwgbWFwcGluZyB3aXRob3V0IGFueSBjaGFuZ2UgdG8gdGhl IG9sZCAKbWFwcGluZyh0aGUgY3B1IGNhbid0IHdhbGsgYWNjZXNzIHRoZSBuZXcgcGFnZSBtYXBw aW5nLCBpdCdzIGlzb2xhdGVkKQoKYi5jaGFuZ2UgdG8gdXNlIGluaXRfcGdfZGlyCgpjLmNsZWFy IHRoZSBvbGQgMUcgYmxvY2sgbWFwcGluZyBhbmQgZmx1c2ggdGxiCgpkLm1vZGlmeSB0aGUgbGlu ZWFyIG1hcHBpbmcgdG8gdXNlIG5ldyBwdGUgbGV2ZWwgcGFnZSBtYXBwaW5nIHdpdGggCmluaXRf cGdfZGlyKFRMQiBCQk0pCgplLnN3aXRjaCB0byBzd2FwcGVyX3BnX2RpcgoKCkNvdWxkIHlvdSBn aXZlIG1lIHNvbWUgYWR2aWNlPwoKVGhhbmtzLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgt YXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3Jn L21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo= 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 9FE0FC433EF for ; Fri, 8 Jul 2022 12:28:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 04A628E0001; Fri, 8 Jul 2022 08:28:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F3C876B0073; Fri, 8 Jul 2022 08:28:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E2C448E0001; Fri, 8 Jul 2022 08:28:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id D02F26B0071 for ; Fri, 8 Jul 2022 08:28:27 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A76BA348F5 for ; Fri, 8 Jul 2022 12:28:27 +0000 (UTC) X-FDA: 79663860654.05.C9B75EF Received: from out30-130.freemail.mail.aliyun.com (out30-130.freemail.mail.aliyun.com [115.124.30.130]) by imf03.hostedemail.com (Postfix) with ESMTP id 98DBF2001A for ; Fri, 8 Jul 2022 12:28:25 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R161e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045170;MF=guanghuifeng@linux.alibaba.com;NM=1;PH=DS;RN=21;SR=0;TI=SMTPD_---0VIjXe4a_1657283299; Received: from 30.225.28.127(mailfrom:guanghuifeng@linux.alibaba.com fp:SMTPD_---0VIjXe4a_1657283299) by smtp.aliyun-inc.com; Fri, 08 Jul 2022 20:28:20 +0800 Message-ID: Date: Fri, 8 Jul 2022 20:28:18 +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 RESEND v4] arm64: mm: fix linear mem mapping access performance degradation To: Catalin Marinas Cc: Mike Rapoport , Will Deacon , Ard Biesheuvel , baolin.wang@linux.alibaba.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, geert+renesas@glider.be, linux-mm@kvack.org, yaohongbo@linux.alibaba.com, alikernel-developer@linux.alibaba.com References: <5d044fdd-a61a-d60f-d294-89e17de37712@linux.alibaba.com> <20220705121115.GB1012@willie-the-truck> <9974bea5-4db9-0104-c9c9-d9b49c390f1b@linux.alibaba.com> From: "guanghui.fgh" In-Reply-To: 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=1657283307; 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=58WrYWFXwqur5Y8O8tCnxHiiJ/fU7eeQFiVF8pY/s1M=; b=Npz1ZLp80IQTP+tdxCaQ9BI5MYeNv/ksmOWP0AKTsoYxa6dEN+DjeLPtbnKU4toa78kFw9 iDAI7W+ynm5qaJvjHBYtzwAFHOW+DLt3oBBkVJoxTg/xeOfIXFwqJVtrUC+7wyfTGObwgq jvX4opPb9Yj5/YJJ0w3amygpUTGSRHQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657283307; a=rsa-sha256; cv=none; b=hKKZHgmreEGLahFm4q7UOH4BHXZYcAlJFVJ1LLoLyBb6jqG4872fNjddbzbn+zhDJmgqv4 IbFEbke/QgYSrp+BTC2DsfUGo3WHqj9xib8Fw8+TbveOtzRTpc+gU0gaPXfLd029gbmZn0 wVRWur3ggqE7Uv3o1p9XP1sIr+aJCVY= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=alibaba.com; spf=pass (imf03.hostedemail.com: domain of guanghuifeng@linux.alibaba.com designates 115.124.30.130 as permitted sender) smtp.mailfrom=guanghuifeng@linux.alibaba.com Authentication-Results: imf03.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=alibaba.com; spf=pass (imf03.hostedemail.com: domain of guanghuifeng@linux.alibaba.com designates 115.124.30.130 as permitted sender) smtp.mailfrom=guanghuifeng@linux.alibaba.com X-Rspamd-Server: rspam02 X-Stat-Signature: dzyrbiahfmbtcw68mmaojcyjm4j841qp X-Rspamd-Queue-Id: 98DBF2001A X-Rspam-User: X-HE-Tag: 1657283305-698774 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/6 23:40, Catalin Marinas 写道: > On Wed, Jul 06, 2022 at 11:18:22PM +0800, guanghui.fgh wrote: >> 在 2022/7/6 21:54, Mike Rapoport 写道: >>> One thing I can think of is to only remap the crash kernel memory if it is >>> a part of an allocation that exactly fits into one ore more PUDs. >>> >>> Say, in reserve_crashkernel() we try the memblock_phys_alloc() with >>> PUD_SIZE as alignment and size rounded up to PUD_SIZE. If this allocation >>> succeeds, we remap the entire area that now contains only memory allocated >>> in reserve_crashkernel() and free the extra memory after remapping is done. >>> If the large allocation fails, we fall back to the original size and >>> alignment and don't allow unmapping crash kernel memory in >>> arch_kexec_protect_crashkres(). >> >> There is a new method. >> I think we should use the patch v3(similar but need add some changes) >> >> 1.We can walk crashkernle block/section pagetable, >> [[[(keep the origin block/section mapping valid]]] >> rebuild the pte level page mapping for the crashkernel mem >> rebuild left & right margin mem(which is in same block/section mapping but >> out of crashkernel mem) with block/section mapping >> >> 2.'replace' the origin block/section mapping by new builded mapping >> iterately >> >> With this method, all the mem mapping keep valid all the time. > > As I already commented on one of your previous patches, this is not > allowed by the architecture. If FEAT_BBM is implemented (ARMv8.4 I > think), the worst that can happen is a TLB conflict abort and the > handler should invalidate the TLBs and restart the faulting instruction, > assuming the handler won't try to access the same conflicting virtual > address. Prior to FEAT_BBM, that's not possible as the architecture does > not describe a precise behaviour of conflicting TLB entries (you might > as well get the TLB output of multiple entries being or'ed together). > The cpu can generate a TLB conflict abort if it detects that the address being looked up in the TLB hits multiple entries. (1).I think when gathering small page to block/section mapping, there maybe tlb conflict if no complying with BBM. Namely: a.Map a 4KB page (address X) Touch that page, in order to get the translation cached in the TLB b.Modify the translation tables replacing the mapping for address X with a 2MB mapping - DO NOT INVALIDATE the TLB c.Touch "X + 4KB" This will/should miss in the TLB, causing a new walk returning the 2MB mapping d.Touch X Assuming they've not been evicted, you'll hit both on the 4KB and 2MB mapping - as both cover address X. There is tlb conflict. (link: https://community.arm.com/support-forums/f/dev-platforms-forum/13583/tlb-conflict-abort) (2).But when spliting large block/section mapping to small granularity, there maybe no tlb conflict. Namely: a.rebuild the pte level mapping without any change to orgin pagetable (the relation between virtual address and physicall address keep same) b.modify 1G mappting to use the new pte level mapping in the [[[mem]]] without tlb flush c.When the cpu access the 1G mem(anywhere), If 1G tlb entry already cached in tlb, all the 1G mem will access success(without any tlb loaded, no confilict) If 1G tlb entry has been evicted, then the tlb will access pagetable in mem(despite the cpu "catch" the old(1G) or new(4k) mapped pagetale in the mem, all the 1G mem can access sucess)(load new tlb entry, no conflict) d.Afterward, we flush the tlb and force cpu use the new pagetable.(no conflict) It seems that there are no two tlb entries for a same virtual address in the tlb cache When spliting large block/section mapping. (3).At the same time, I think we can use another way. As the system linear maping is builded with init_pg_dir, we can also resue the init_pg_dir to split the block/setion mapping sometime. As init_pg_dir contain all kernel text/data access and we can comply with the BBM requirement. a.rebuild new pte level mapping without any change to the old mapping(the cpu can't walk access the new page mapping, it's isolated) b.change to use init_pg_dir c.clear the old 1G block mapping and flush tlb d.modify the linear mapping to use new pte level page mapping with init_pg_dir(TLB BBM) e.switch to swapper_pg_dir Could you give me some advice? Thanks.