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 19832C43334 for ; Wed, 6 Jul 2022 15:31:50 +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:References:Cc:To:From: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=bOZxE6aHgGLu1F7Jq4E1i8947YtIsGmH1T8Gu7VOwCo=; b=Fv6VXgVxyF5Kku YljrWNqItWtqlGEVUoXQDfK2JWDnzIkd1F6nqNPgQ7KAsu2i5m+Z+k64a0ERSi+IKMZI4jmc4sufC 2A/iEuIgjN3OcgCecXjT9PM+FUlHxbVKn53An/aUE+MChV/dp98Yjw0v23waVufI94AX4+MJozpPU uvAb3Il0oNdqVviDfosgu0bAuQIuJzwNA5JAT5yrg263kRBR3Mn8V9eU2qUkLpOj4QDClnWt2swNL RMogXLuVJCXDzPpHPjmUcjbuu2iFd7cIMh9CCmwBbBXZHmrpgorQfDaLzP/k/qeI7ZVgC/k3T8kNv 9MDuTN7GTos75jQjfOBQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o96z6-00B24V-9T; Wed, 06 Jul 2022 15:30:36 +0000 Received: from out30-57.freemail.mail.aliyun.com ([115.124.30.57]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1o96z1-00B22U-Ey for linux-arm-kernel@lists.infradead.org; Wed, 06 Jul 2022 15:30:34 +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=ay29a033018046049;MF=guanghuifeng@linux.alibaba.com;NM=1;PH=DS;RN=21;SR=0;TI=SMTPD_---0VIYaXRV_1657121420; Received: from 30.225.28.170(mailfrom:guanghuifeng@linux.alibaba.com fp:SMTPD_---0VIYaXRV_1657121420) by smtp.aliyun-inc.com; Wed, 06 Jul 2022 23:30:21 +0800 Message-ID: <5e73380a-be07-a3fe-8ee2-e38cd7f8fb2a@linux.alibaba.com> Date: Wed, 6 Jul 2022 23:30:19 +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 From: "guanghui.fgh" To: Mike Rapoport , Catalin Marinas Cc: 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: <20220705095231.GB552@willie-the-truck> <5d044fdd-a61a-d60f-d294-89e17de37712@linux.alibaba.com> <20220705121115.GB1012@willie-the-truck> <9974bea5-4db9-0104-c9c9-d9b49c390f1b@linux.alibaba.com> In-Reply-To: <9974bea5-4db9-0104-c9c9-d9b49c390f1b@linux.alibaba.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220706_083031_940694_63EE3131 X-CRM114-Status: GOOD ( 23.41 ) 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 CgrlnKggMjAyMi83LzYgMjM6MTgsIGd1YW5naHVpLmZnaCDlhpnpgZM6Cj4gVGhhbmtzLgo+IAo+ IOWcqCAyMDIyLzcvNiAyMTo1NCwgTWlrZSBSYXBvcG9ydCDlhpnpgZM6Cj4+IE9uIFdlZCwgSnVs IDA2LCAyMDIyIGF0IDExOjA0OjI0QU0gKzAxMDAsIENhdGFsaW4gTWFyaW5hcyB3cm90ZToKPj4+ IE9uIFR1ZSwgSnVsIDA1LCAyMDIyIGF0IDExOjQ1OjQwUE0gKzAzMDAsIE1pa2UgUmFwb3BvcnQg d3JvdGU6Cj4+Pj4gT24gVHVlLCBKdWwgMDUsIDIwMjIgYXQgMDY6MDU6MDFQTSArMDEwMCwgQ2F0 YWxpbiBNYXJpbmFzIHdyb3RlOgo+Pj4+PiBPbiBUdWUsIEp1bCAwNSwgMjAyMiBhdCAwNjo1Nzo1 M1BNICswMzAwLCBNaWtlIFJhcG9wb3J0IHdyb3RlOgo+Pj4+Pj4gT24gVHVlLCBKdWwgMDUsIDIw MjIgYXQgMDQ6MzQ6MDlQTSArMDEwMCwgQ2F0YWxpbiBNYXJpbmFzIHdyb3RlOgo+Pj4+Pj4+IE9u IFR1ZSwgSnVsIDA1LCAyMDIyIGF0IDA2OjAyOjAyUE0gKzAzMDAsIE1pa2UgUmFwb3BvcnQgd3Jv dGU6Cj4+Pj4+Pj4+ICt2b2lkIF9faW5pdCByZW1hcF9jcmFzaGtlcm5lbCh2b2lkKQo+Pj4+Pj4+ PiArewo+Pj4+Pj4+PiArI2lmZGVmIENPTkZJR19LRVhFQ19DT1JFCj4+Pj4+Pj4+ICvCoMKgwqAg cGh5c19hZGRyX3Qgc3RhcnQsIGVuZCwgc2l6ZTsKPj4+Pj4+Pj4gK8KgwqDCoCBwaHlzX2FkZHJf dCBhbGlnbmVkX3N0YXJ0LCBhbGlnbmVkX2VuZDsKPj4+Pj4+Pj4gKwo+Pj4+Pj4+PiArwqDCoMKg IGlmIChjYW5fc2V0X2RpcmVjdF9tYXAoKSB8fCBJU19FTkFCTEVEKENPTkZJR19LRkVOQ0UpKQo+ Pj4+Pj4+PiArwqDCoMKgwqDCoMKgwqAgcmV0dXJuOwo+Pj4+Pj4+PiArCj4+Pj4+Pj4+ICvCoMKg wqAgaWYgKCFjcmFzaGtfcmVzLmVuZCkKPj4+Pj4+Pj4gK8KgwqDCoMKgwqDCoMKgIHJldHVybjsK Pj4+Pj4+Pj4gKwo+Pj4+Pj4+PiArwqDCoMKgIHN0YXJ0ID0gY3Jhc2hrX3Jlcy5zdGFydCAmIFBB R0VfTUFTSzsKPj4+Pj4+Pj4gK8KgwqDCoCBlbmQgPSBQQUdFX0FMSUdOKGNyYXNoa19yZXMuZW5k KTsKPj4+Pj4+Pj4gKwo+Pj4+Pj4+PiArwqDCoMKgIGFsaWduZWRfc3RhcnQgPSBBTElHTl9ET1dO KGNyYXNoa19yZXMuc3RhcnQsIFBVRF9TSVpFKTsKPj4+Pj4+Pj4gK8KgwqDCoCBhbGlnbmVkX2Vu ZCA9IEFMSUdOKGVuZCwgUFVEX1NJWkUpOwo+Pj4+Pj4+PiArCj4+Pj4+Pj4+ICvCoMKgwqAgLyog Q2xlYXIgUFVEcyBjb250YWluaW5nIGNyYXNoIGtlcm5lbCBtZW1vcnkgKi8KPj4+Pj4+Pj4gK8Kg wqDCoCB1bm1hcF9ob3RwbHVnX3JhbmdlKF9fcGh5c190b192aXJ0KGFsaWduZWRfc3RhcnQpLAo+ Pj4+Pj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIF9fcGh5c190b192aXJ0KGFs aWduZWRfZW5kKSwgZmFsc2UsIE5VTEwpOwo+Pj4+Pj4+Cj4+Pj4+Pj4gV2hhdCBJIGRvbid0IHVu ZGVyc3RhbmQgaXMgd2hhdCBoYXBwZW5zIGlmIHRoZXJlJ3MgdmFsaWQga2VybmVsIGRhdGEKPj4+ Pj4+PiBiZXR3ZWVuIGFsaWduZWRfc3RhcnQgYW5kIGNyYXNoa19yZXMuc3RhcnQgKG9yIHRoZSBv dGhlciBlbmQgb2YgdGhlCj4+Pj4+Pj4gcmFuZ2UpLgo+Pj4+Pj4KPj4+Pj4+IERhdGEgc2hvdWxk bid0IGdvIGFueXdoZXJlIDopCj4+Pj4+Pgo+Pj4+Pj4gVGhlcmUgaXMKPj4+Pj4+Cj4+Pj4+PiAr wqDCoMKgIC8qIG1hcCBhcmVhIGZyb20gUFVEIHN0YXJ0IHRvIHN0YXJ0IG9mIGNyYXNoIGtlcm5l bCB3aXRoIAo+Pj4+Pj4gbGFyZ2UgcGFnZXMgKi8KPj4+Pj4+ICvCoMKgwqAgc2l6ZSA9IHN0YXJ0 IC0gYWxpZ25lZF9zdGFydDsKPj4+Pj4+ICvCoMKgwqAgX19jcmVhdGVfcGdkX21hcHBpbmcoc3dh cHBlcl9wZ19kaXIsIGFsaWduZWRfc3RhcnQsCj4+Pj4+PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgX19waHlzX3RvX3ZpcnQoYWxpZ25lZF9zdGFydCksCj4+Pj4+PiArwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgc2l6ZSwgUEFHRV9LRVJORUwsIGVhcmx5X3BndGFi bGVfYWxsb2MsIDApOwo+Pj4+Pj4KPj4+Pj4+IGFuZAo+Pj4+Pj4KPj4+Pj4+ICvCoMKgwqAgLyog bWFwIGFyZWEgZnJvbSBlbmQgb2YgY3Jhc2gga2VybmVsIHRvIFBVRCBlbmQgd2l0aCBsYXJnZSAK Pj4+Pj4+IHBhZ2VzICovCj4+Pj4+PiArwqDCoMKgIHNpemUgPSBhbGlnbmVkX2VuZCAtIGVuZDsK Pj4+Pj4+ICvCoMKgwqAgX19jcmVhdGVfcGdkX21hcHBpbmcoc3dhcHBlcl9wZ19kaXIsIGVuZCwg X19waHlzX3RvX3ZpcnQoZW5kKSwKPj4+Pj4+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCBzaXplLCBQQUdFX0tFUk5FTCwgZWFybHlfcGd0YWJsZV9hbGxvYywgMCk7Cj4+Pj4+Pgo+ Pj4+Pj4gYWZ0ZXIgdGhlIHVubWFwLCBzbyBhZnRlciB3ZSB0ZWFyIGRvd24gYSBwYXJ0IG9mIGEg bGluZWFyIG1hcCB3ZQo+Pj4+Pj4gaW1tZWRpYXRlbHkgcmVjcmVhdGUgaXQsIGp1c3Qgd2l0aCBh IGRpZmZlcmVudCBwYWdlIHNpemUuCj4+Pj4+Pgo+Pj4+Pj4gVGhpcyBhbGwgaGFwcGVucyBiZWZv cmUgU01QLCBzbyB0aGVyZSBpcyBubyBjb25jdXJyZW5jeSBhdCB0aGF0IAo+Pj4+Pj4gcG9pbnQu Cj4+Pj4+Cj4+Pj4+IFRoYXQgYnJpZWYgcGVyaW9kIG9mIHVubWFwIHdvcnJpZXMgbWUuIFRoZSBr ZXJuZWwgdGV4dCwgZGF0YSBhbmQgc3RhY2sKPj4+Pj4gYXJlIGFsbCBpbiB0aGUgdm1hbGxvYyBz cGFjZSBidXQgYW55IG90aGVyIChtZW1ibG9jaykgYWxsb2NhdGlvbiB0byAKPj4+Pj4gdGhpcwo+ Pj4+PiBwb2ludCBtYXkgYmUgaW4gdGhlIHVubWFwcGVkIHJhbmdlIGJlZm9yZSBhbmQgYWZ0ZXIg dGhlIGNyYXNoa2VybmVsCj4+Pj4+IHJlc2VydmF0aW9uLiBUaGUgaW50ZXJydXB0cyBhcmUgb2Zm LCBzbyBJIHRoaW5rIHRoZSBvbmx5IGFsbG9jYXRpb24gCj4+Pj4+IGFuZAo+Pj4+PiBwb3RlbnRp YWwgYWNjZXNzIHRoYXQgbWF5IGdvIGluIHRoaXMgcmFuZ2UgaXMgdGhlIHBhZ2UgdGFibGUgCj4+ Pj4+IGl0c2VsZi4gQnV0Cj4+Pj4+IGl0IGxvb2tzIGZyYWdpbGUgdG8gbWUuCj4+Pj4KPj4+PiBJ IGFncmVlIHRoZXJlIGFyZSBjaGFuY2VzIHRoZXJlIHdpbGwgYmUgYW4gYWxsb2NhdGlvbiBmcm9t IHRoZSB1bm1hcHBlZAo+Pj4+IHJhbmdlLgo+Pj4+Cj4+Pj4gV2UgY2FuIG1ha2Ugc3VyZSB0aGlz IHdvbid0IGhhcHBlbiwgdGhvdWdoLiBXZSBjYW4gY2FwIHRoZSBtZW1ibG9jawo+Pj4+IGFsbG9j YXRpb25zIHdpdGggbWVtYmxvY2tfc2V0X2N1cnJlbnRfbGltaXQoYWxpZ25lZF9lbmQpIG9yCj4+ Pj4gbWVtYmxvY2tfcmVzZXJ2ZShhbGdpbmVkX3N0YXJ0LCBhbGlnbmVkX2VuZCkgdW50aWwgdGhl IG1hcHBpbmdzIGFyZQo+Pj4+IHJlc3RvcmVkLgo+Pj4KPj4+IFdlIGNhbiByZXNlcnZlIHRoZSBy ZWdpb24ganVzdCBiZWZvcmUgdW5tYXBwaW5nIHRvIGF2b2lkIG5ldyBhbGxvY2F0aW9ucwo+Pj4g Zm9yIHRoZSBwYWdlIHRhYmxlcyBidXQgd2UgY2FuJ3QgZG8gbXVjaCBhYm91dCBwYWdlcyBhbHJl YWR5IGFsbG9jYXRlZAo+Pj4gcHJpb3IgdG8gY2FsbGluZyByZW1hcF9jcmFzaGtlcm5lbCgpLgo+ Pgo+PiBSaWdodCwgdGhpcyB3YXMgYm90aGVyaW5nIG1lIHRvbyBhZnRlciBJIHJlLXJlYWQgeW91 IHByZXZpb3VzIGVtYWlsLgo+Pgo+PiBPbmUgdGhpbmcgSSBjYW4gdGhpbmsgb2YgaXMgdG8gb25s eSByZW1hcCB0aGUgY3Jhc2gga2VybmVsIG1lbW9yeSBpZiAKPj4gaXQgaXMKPj4gYSBwYXJ0IG9m IGFuIGFsbG9jYXRpb24gdGhhdCBleGFjdGx5IGZpdHMgaW50byBvbmUgb3JlIG1vcmUgUFVEcy4K Pj4KPj4gU2F5LCBpbiByZXNlcnZlX2NyYXNoa2VybmVsKCkgd2UgdHJ5IHRoZSBtZW1ibG9ja19w aHlzX2FsbG9jKCkgd2l0aAo+PiBQVURfU0laRSBhcyBhbGlnbm1lbnQgYW5kIHNpemUgcm91bmRl ZCB1cCB0byBQVURfU0laRS4gSWYgdGhpcyBhbGxvY2F0aW9uCj4+IHN1Y2NlZWRzLCB3ZSByZW1h cCB0aGUgZW50aXJlIGFyZWEgdGhhdCBub3cgY29udGFpbnMgb25seSBtZW1vcnkgCj4+IGFsbG9j YXRlZAo+PiBpbiByZXNlcnZlX2NyYXNoa2VybmVsKCkgYW5kIGZyZWUgdGhlIGV4dHJhIG1lbW9y eSBhZnRlciByZW1hcHBpbmcgaXMgCj4+IGRvbmUuCj4+IElmIHRoZSBsYXJnZSBhbGxvY2F0aW9u IGZhaWxzLCB3ZSBmYWxsIGJhY2sgdG8gdGhlIG9yaWdpbmFsIHNpemUgYW5kCj4+IGFsaWdubWVu dCBhbmQgZG9uJ3QgYWxsb3cgdW5tYXBwaW5nIGNyYXNoIGtlcm5lbCBtZW1vcnkgaW4KPj4gYXJj aF9rZXhlY19wcm90ZWN0X2NyYXNoa3JlcygpLgo+Pj4gLS0gCj4+PiBDYXRhbGluCj4+Cj4gVGhh bmtzLgo+IAo+IFRoZXJlIGlzIGEgbmV3IG1ldGhvZC4KPiBJIHRoaW5rIHdlIHNob3VsZCB1c2Ug dGhlIHBhdGNoIHYzKHNpbWlsYXIgYnV0IG5lZWQgYWRkIHNvbWUgY2hhbmdlcykKPiAKPiAxLldl IGNhbiB3YWxrIGNyYXNoa2VybmxlIGJsb2NrL3NlY3Rpb24gcGFnZXRhYmxlLAo+IFtbWyhrZWVw IHRoZSBvcmlnaW4gYmxvY2svc2VjdGlvbiBtYXBwaW5nIHZhbGlkXV1dCj4gcmVidWlsZCB0aGUg cHRlIGxldmVsIHBhZ2UgbWFwcGluZyBmb3IgdGhlIGNyYXNoa2VybmVsIG1lbQo+IHJlYnVpbGQg bGVmdCAmIHJpZ2h0IG1hcmdpbiBtZW0od2hpY2ggaXMgaW4gc2FtZSBibG9jay9zZWN0aW9uIG1h cHBpbmcgCj4gYnV0IG91dCBvZiBjcmFzaGtlcm5lbCBtZW0pIHdpdGggYmxvY2svc2VjdGlvbiBt YXBwaW5nCj4gCj4gMi4ncmVwbGFjZScgdGhlIG9yaWdpbiBibG9jay9zZWN0aW9uIG1hcHBpbmcg YnkgbmV3IGJ1aWxkZWQgbWFwcGluZyAKPiBpdGVyYXRlbHkKPiAKPiBXaXRoIHRoaXMgbWV0aG9k LCBhbGwgdGhlIG1lbSBtYXBwaW5nIGtlZXAgdmFsaWQgYWxsIHRoZSB0aW1lLgo+IAo+IDMudGhl IHBhdGNoIHYzIGxpbms6Cj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcvbGludXgtbW0vNmRjMzA4 ZGItMzY4NS00ZGY1LTUwNmEtNzFmOWUzNzk0ZWM4QGxpbnV4LmFsaWJhYmEuY29tL1QvIAo+IAo+ IChOZWVkIHNvbWUgY2hhbmdlcykKCk5hbWVseSwKV2hlbiByZWJ1aWxkaW5nIGZvciBjcmFzaGtl cm5lbCBtZW0gcGFnZW1hcHBpbmcsIHRoZXJlIGlzIG5vIGNoYW5nZSB0byAKdGhlIG9yaWdpbiBt YXBwaW5nLgoKV2hlbiB0aGUgbmV3IG1hcHBpbmcgaXMgcmVhZHksIHdlIHJlcGxhY2Ugb2xkIG1h cHBpbmcgd2l0aCB0aGUgbmV3IApidWlsZGVkIG1hcHBpbmcuCgpXaXRoIHRoaXMgbWV0aG9kLCBr ZWVwIGFsbCBtZW0gbWFwcGluZyB2YWxpZCBhbGwgdGhlIHRpbWUuCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcg bGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmlu ZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg== 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 854A8CCA473 for ; Wed, 6 Jul 2022 15:30:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0004D6B0074; Wed, 6 Jul 2022 11:30:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EF2F26B0075; Wed, 6 Jul 2022 11:30:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DE24C6B0078; Wed, 6 Jul 2022 11:30:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id CF91D6B0074 for ; Wed, 6 Jul 2022 11:30:30 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A096634445 for ; Wed, 6 Jul 2022 15:30:30 +0000 (UTC) X-FDA: 79657061820.29.24FDCA3 Received: from out30-131.freemail.mail.aliyun.com (out30-131.freemail.mail.aliyun.com [115.124.30.131]) by imf15.hostedemail.com (Postfix) with ESMTP id C0B7FA0056 for ; Wed, 6 Jul 2022 15:30:26 +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=ay29a033018046049;MF=guanghuifeng@linux.alibaba.com;NM=1;PH=DS;RN=21;SR=0;TI=SMTPD_---0VIYaXRV_1657121420; Received: from 30.225.28.170(mailfrom:guanghuifeng@linux.alibaba.com fp:SMTPD_---0VIYaXRV_1657121420) by smtp.aliyun-inc.com; Wed, 06 Jul 2022 23:30:21 +0800 Message-ID: <5e73380a-be07-a3fe-8ee2-e38cd7f8fb2a@linux.alibaba.com> Date: Wed, 6 Jul 2022 23:30:19 +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 From: "guanghui.fgh" To: Mike Rapoport , Catalin Marinas Cc: 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: <20220705095231.GB552@willie-the-truck> <5d044fdd-a61a-d60f-d294-89e17de37712@linux.alibaba.com> <20220705121115.GB1012@willie-the-truck> <9974bea5-4db9-0104-c9c9-d9b49c390f1b@linux.alibaba.com> In-Reply-To: <9974bea5-4db9-0104-c9c9-d9b49c390f1b@linux.alibaba.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657121430; a=rsa-sha256; cv=none; b=v1qByuQ5q8bIWzXxgJ9HRt/eq219B96lCCstgx1g9eKi9uUPZJLHPg6HvlJ7QUNx2ZyiVF qzSH2Fo5VUJyIpu45oWeEf7Xy5MjQwUCLm3t+CfiiES0zWXPhGU/Z69ZpFye0NLE7j41Cw eRelCLuj5Xf+ZcdeUsuPywnO/zZ55sI= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=alibaba.com; spf=pass (imf15.hostedemail.com: domain of guanghuifeng@linux.alibaba.com designates 115.124.30.131 as permitted sender) smtp.mailfrom=guanghuifeng@linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657121430; 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=VnSyUwE8slh+nBjCTzHuZQxiVPMc72e0sp8eYaNrrSo=; b=yJP9h1GZ0T+4CKCzPSvPkroOj+sUt5hrkunG2ysXCRWbGlXJL0cAzH3JBq8Nlx9RnZjzOd ioBSrkOW7r8PGmrqx90X3kS9i0uEF7gS9ABgoUb7qA1VXbcBWnSPFx574jK9qeA8IjBc3+ /iJCFPO6Rx8zGifyVYgsXwzeQ+TttDk= X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: C0B7FA0056 X-Rspam-User: Authentication-Results: imf15.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=alibaba.com; spf=pass (imf15.hostedemail.com: domain of guanghuifeng@linux.alibaba.com designates 115.124.30.131 as permitted sender) smtp.mailfrom=guanghuifeng@linux.alibaba.com X-Stat-Signature: 7ne8bkcu7ccg5udmfewnirctukh9kg3i X-HE-Tag: 1657121426-346144 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: 在 2022/7/6 23:18, guanghui.fgh 写道: > Thanks. > > 在 2022/7/6 21:54, Mike Rapoport 写道: >> On Wed, Jul 06, 2022 at 11:04:24AM +0100, Catalin Marinas wrote: >>> On Tue, Jul 05, 2022 at 11:45:40PM +0300, Mike Rapoport wrote: >>>> On Tue, Jul 05, 2022 at 06:05:01PM +0100, Catalin Marinas wrote: >>>>> On Tue, Jul 05, 2022 at 06:57:53PM +0300, Mike Rapoport wrote: >>>>>> On Tue, Jul 05, 2022 at 04:34:09PM +0100, Catalin Marinas wrote: >>>>>>> On Tue, Jul 05, 2022 at 06:02:02PM +0300, Mike Rapoport wrote: >>>>>>>> +void __init remap_crashkernel(void) >>>>>>>> +{ >>>>>>>> +#ifdef CONFIG_KEXEC_CORE >>>>>>>> +    phys_addr_t start, end, size; >>>>>>>> +    phys_addr_t aligned_start, aligned_end; >>>>>>>> + >>>>>>>> +    if (can_set_direct_map() || IS_ENABLED(CONFIG_KFENCE)) >>>>>>>> +        return; >>>>>>>> + >>>>>>>> +    if (!crashk_res.end) >>>>>>>> +        return; >>>>>>>> + >>>>>>>> +    start = crashk_res.start & PAGE_MASK; >>>>>>>> +    end = PAGE_ALIGN(crashk_res.end); >>>>>>>> + >>>>>>>> +    aligned_start = ALIGN_DOWN(crashk_res.start, PUD_SIZE); >>>>>>>> +    aligned_end = ALIGN(end, PUD_SIZE); >>>>>>>> + >>>>>>>> +    /* Clear PUDs containing crash kernel memory */ >>>>>>>> +    unmap_hotplug_range(__phys_to_virt(aligned_start), >>>>>>>> +                __phys_to_virt(aligned_end), false, NULL); >>>>>>> >>>>>>> What I don't understand is what happens if there's valid kernel data >>>>>>> between aligned_start and crashk_res.start (or the other end of the >>>>>>> range). >>>>>> >>>>>> Data shouldn't go anywhere :) >>>>>> >>>>>> There is >>>>>> >>>>>> +    /* map area from PUD start to start of crash kernel with >>>>>> large pages */ >>>>>> +    size = start - aligned_start; >>>>>> +    __create_pgd_mapping(swapper_pg_dir, aligned_start, >>>>>> +                 __phys_to_virt(aligned_start), >>>>>> +                 size, PAGE_KERNEL, early_pgtable_alloc, 0); >>>>>> >>>>>> and >>>>>> >>>>>> +    /* map area from end of crash kernel to PUD end with large >>>>>> pages */ >>>>>> +    size = aligned_end - end; >>>>>> +    __create_pgd_mapping(swapper_pg_dir, end, __phys_to_virt(end), >>>>>> +                 size, PAGE_KERNEL, early_pgtable_alloc, 0); >>>>>> >>>>>> after the unmap, so after we tear down a part of a linear map we >>>>>> immediately recreate it, just with a different page size. >>>>>> >>>>>> This all happens before SMP, so there is no concurrency at that >>>>>> point. >>>>> >>>>> That brief period of unmap worries me. The kernel text, data and stack >>>>> are all in the vmalloc space but any other (memblock) allocation to >>>>> this >>>>> point may be in the unmapped range before and after the crashkernel >>>>> reservation. The interrupts are off, so I think the only allocation >>>>> and >>>>> potential access that may go in this range is the page table >>>>> itself. But >>>>> it looks fragile to me. >>>> >>>> I agree there are chances there will be an allocation from the unmapped >>>> range. >>>> >>>> We can make sure this won't happen, though. We can cap the memblock >>>> allocations with memblock_set_current_limit(aligned_end) or >>>> memblock_reserve(algined_start, aligned_end) until the mappings are >>>> restored. >>> >>> We can reserve the region just before unmapping to avoid new allocations >>> for the page tables but we can't do much about pages already allocated >>> prior to calling remap_crashkernel(). >> >> Right, this was bothering me too after I re-read you previous email. >> >> 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(). >>> -- >>> Catalin >> > Thanks. > > 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. > > 3.the patch v3 link: > https://lore.kernel.org/linux-mm/6dc308db-3685-4df5-506a-71f9e3794ec8@linux.alibaba.com/T/ > > (Need some changes) Namely, When rebuilding for crashkernel mem pagemapping, there is no change to the origin mapping. When the new mapping is ready, we replace old mapping with the new builded mapping. With this method, keep all mem mapping valid all the time.