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 X-Spam-Level: X-Spam-Status: No, score=-12.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DB17EC43464 for ; Mon, 21 Sep 2020 12:43:02 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 419A8207BC for ; Mon, 21 Sep 2020 12:43:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="W5QilM5J" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 419A8207BC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=E1kZyaVWgJp6H2fnYRaCr6u5DIzE43w7F4Q1JjYv4w8=; b=W5QilM5J9R14y/iP/U94JDE3b hZ9crM4Q1doSplcl+jjxgBJrl5DtzwLH6fwSNll9uMjRsN/X/NhLXE8PGwf8cp/eWIaWEx9GoJxxg qnZqqBnWsmz8TInadC/H9iob12Di1rSxisGy9JPpmKaTNVZEM/kGcFb40cdTmtDtU1ClYZ3vEG3o+ yloC4gGyk4wCIVvDz/lb32HJ9kOGZRkPo6+uMuNJYpL9azow/7KW324V4uMdzj480Hbk9ii3Ig7tL S12vlqnibKf4BXEg6rdjJtBsLysmIRbCRycOudIH9MCzLDwQiDt+41Fq9TEroifuFsoZNyQgUw0HS T6OFLThvg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kKL8G-0001H9-E4; Mon, 21 Sep 2020 12:41:24 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kKL8B-0001GW-6b for linux-arm-kernel@lists.infradead.org; Mon, 21 Sep 2020 12:41:20 +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 1F2EED6E; Mon, 21 Sep 2020 05:41:16 -0700 (PDT) Received: from [10.163.75.158] (unknown [10.163.75.158]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C0AA83F73B; Mon, 21 Sep 2020 05:41:13 -0700 (PDT) Subject: Re: [PATCH 2/2] arm64/mm: Enable color zero pages To: Gavin Shan , Robin Murphy , Will Deacon References: <20200916032523.13011-1-gshan@redhat.com> <20200916032523.13011-3-gshan@redhat.com> <20200916082819.GB27496@willie-the-truck> <33e9a04e-9f93-6a06-273d-284900bc1535@arm.com> <968a5ae7-ebed-8191-15df-6c9860dc72fe@redhat.com> From: Anshuman Khandual Message-ID: Date: Mon, 21 Sep 2020 18:10:33 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <968a5ae7-ebed-8191-15df-6c9860dc72fe@redhat.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200921_084119_332176_28910270 X-CRM114-Status: GOOD ( 41.44 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, catalin.marinas@arm.com, linux-kernel@vger.kernel.org, shan.gavin@gmail.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org CgpPbiAwOS8yMS8yMDIwIDA4OjI2IEFNLCBHYXZpbiBTaGFuIHdyb3RlOgo+IEhpIFJvYmluLAo+ IAo+IE9uIDkvMTcvMjAgODoyMiBQTSwgUm9iaW4gTXVycGh5IHdyb3RlOgo+PiBPbiAyMDIwLTA5 LTE3IDA0OjM1LCBHYXZpbiBTaGFuIHdyb3RlOgo+Pj4gT24gOS8xNi8yMCA2OjI4IFBNLCBXaWxs IERlYWNvbiB3cm90ZToKPj4+PiBPbiBXZWQsIFNlcCAxNiwgMjAyMCBhdCAwMToyNToyM1BNICsx MDAwLCBHYXZpbiBTaGFuIHdyb3RlOgo+Pj4+PiBUaGlzIGVuYWJsZXMgY29sb3IgemVybyBwYWdl cyBieSBhbGxvY2F0aW5nIGNvbnRpZ291cyBwYWdlIGZyYW1lcwo+Pj4+PiBmb3IgaXQuIFRoZSBu dW1iZXIgb2YgcGFnZXMgZm9yIHRoaXMgaXMgZGV0ZXJtaW5lZCBieSBMMSBkQ2FjaGUKPj4+Pj4g KG9yIGlDYWNoZSkgc2l6ZSwgd2hpY2ggaXMgcHJvYmJlZCBmcm9tIHRoZSBoYXJkd2FyZS4KPj4+ Pj4KPj4+Pj4gwqDCoMKgICogQWRkIGNhY2hlX3RvdGFsX3NpemUoKSB0byByZXR1cm4gTDEgZENh Y2hlIChvciBpQ2FjaGUpIHNpemUKPj4+Pj4KPj4+Pj4gwqDCoMKgICogSW1wbGVtZW50IHNldHVw X3plcm9fcGFnZXMoKSwgd2hpY2ggaXMgY2FsbGVkIGFmdGVyIHRoZSBwYWdlCj4+Pj4+IMKgwqDC oMKgwqAgYWxsb2NhdG9yIGJlZ2lucyB0byB3b3JrLCB0byBhbGxvY2F0ZSB0aGUgY29udGlnb3Vz IHBhZ2VzCj4+Pj4+IMKgwqDCoMKgwqAgbmVlZGVkIGJ5IGNvbG9yIHplcm8gcGFnZS4KPj4+Pj4K Pj4+Pj4gwqDCoMKgICogUmV3b3JrZWQgWkVST19QQUdFKCkgYW5kIGRlZmluZSBfX0hBVkVfQ09M T1JfWkVST19QQUdFLgo+Pj4+Pgo+Pj4+PiBTaWduZWQtb2ZmLWJ5OiBHYXZpbiBTaGFuIDxnc2hh bkByZWRoYXQuY29tPgo+Pj4+PiAtLS0KPj4+Pj4gwqAgYXJjaC9hcm02NC9pbmNsdWRlL2FzbS9j YWNoZS5owqDCoCB8IDIyICsrKysrKysrKysrKysrKysrKysrCj4+Pj4+IMKgIGFyY2gvYXJtNjQv aW5jbHVkZS9hc20vcGd0YWJsZS5oIHzCoCA5ICsrKysrKy0tCj4+Pj4+IMKgIGFyY2gvYXJtNjQv a2VybmVsL2NhY2hlaW5mby5jwqDCoMKgIHwgMzQgKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKwo+Pj4+PiDCoCBhcmNoL2FybTY0L21tL2luaXQuY8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCB8IDM1ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCj4+Pj4+IMKgIGFyY2gvYXJt NjQvbW0vbW11LmPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqAgNyAtLS0tLS0tCj4+Pj4+ IMKgIDUgZmlsZXMgY2hhbmdlZCwgOTggaW5zZXJ0aW9ucygrKSwgOSBkZWxldGlvbnMoLSkKPj4+ Pj4KPj4+Pj4gZGlmZiAtLWdpdCBhL2FyY2gvYXJtNjQvaW5jbHVkZS9hc20vY2FjaGUuaCBiL2Fy Y2gvYXJtNjQvaW5jbHVkZS9hc20vY2FjaGUuaAo+Pj4+PiBpbmRleCBhNGQxYjVmNzcxZjYuLjQy MGU5ZGRlMmM1MSAxMDA2NDQKPj4+Pj4gLS0tIGEvYXJjaC9hcm02NC9pbmNsdWRlL2FzbS9jYWNo ZS5oCj4+Pj4+ICsrKyBiL2FyY2gvYXJtNjQvaW5jbHVkZS9hc20vY2FjaGUuaAo+Pj4+PiBAQCAt MzksNiArMzksMjcgQEAKPj4+Pj4gwqAgI2RlZmluZSBDTElEUl9MT0MoY2xpZHIpwqDCoMKgICgo KGNsaWRyKSA+PiBDTElEUl9MT0NfU0hJRlQpICYgMHg3KQo+Pj4+PiDCoCAjZGVmaW5lIENMSURS X0xPVUlTKGNsaWRyKcKgwqDCoCAoKChjbGlkcikgPj4gQ0xJRFJfTE9VSVNfU0hJRlQpICYgMHg3 KQo+Pj4+PiArI2RlZmluZSBDU1NFTFJfVE5EX1NISUZUwqDCoMKgIDQKPj4+Pj4gKyNkZWZpbmUg Q1NTRUxSX1RORF9NQVNLwqDCoMKgwqDCoMKgwqAgKFVMKDEpIDw8IENTU0VMUl9UTkRfU0hJRlQp Cj4+Pj4+ICsjZGVmaW5lIENTU0VMUl9MRVZFTF9TSElGVMKgwqDCoCAxCj4+Pj4+ICsjZGVmaW5l IENTU0VMUl9MRVZFTF9NQVNLwqDCoMKgIChVTCg3KSA8PCBDU1NFTFJfTEVWRUxfU0hJRlQpCj4+ Pj4+ICsjZGVmaW5lIENTU0VMUl9JTkRfU0hJRlTCoMKgwqAgMAo+Pj4+PiArI2RlZmluZSBDU1NF UkxfSU5EX01BU0vCoMKgwqDCoMKgwqDCoCAoVUwoMSkgPDwgQ1NTRUxSX0lORF9TSElGVCkKPj4+ Pj4gKwo+Pj4+PiArI2RlZmluZSBDQ1NJRFJfNjRfTFNfU0hJRlTCoMKgwqAgMAo+Pj4+PiArI2Rl ZmluZSBDQ1NJRFJfNjRfTFNfTUFTS8KgwqDCoCAoVUwoNykgPDwgQ0NTSURSXzY0X0xTX1NISUZU KQo+Pj4+PiArI2RlZmluZSBDQ1NJRFJfNjRfQVNTT0NfU0hJRlTCoMKgwqAgMwo+Pj4+PiArI2Rl ZmluZSBDQ1NJRFJfNjRfQVNTT0NfTUFTS8KgwqDCoCAoVUwoMHgxRkZGRkYpIDw8IENDU0lEUl82 NF9BU1NPQ19TSElGVCkKPj4+Pj4gKyNkZWZpbmUgQ0NTSURSXzY0X1NFVF9TSElGVMKgwqDCoCAz Mgo+Pj4+PiArI2RlZmluZSBDQ1NJRFJfNjRfU0VUX01BU0vCoMKgwqAgKFVMKDB4RkZGRkZGKSA8 PCBDQ1NJRFJfNjRfU0VUX1NISUZUKQo+Pj4+PiArCj4+Pj4+ICsjZGVmaW5lIENDU0lEUl8zMl9M U19TSElGVMKgwqDCoCAwCj4+Pj4+ICsjZGVmaW5lIENDU0lEUl8zMl9MU19NQVNLwqDCoMKgIChV TCg3KSA8PCBDQ1NJRFJfMzJfTFNfU0hJRlQpCj4+Pj4+ICsjZGVmaW5lIENDU0lEUl8zMl9BU1NP Q19TSElGVMKgwqDCoCAzCj4+Pj4+ICsjZGVmaW5lIENDU0lEUl8zMl9BU1NPQ19NQVNLwqDCoMKg IChVTCgweDNGRikgPDwgQ0NTSURSXzMyX0FTU09DX1NISUZUKQo+Pj4+PiArI2RlZmluZSBDQ1NJ RFJfMzJfU0VUX1NISUZUwqDCoMKgIDEzCj4+Pj4+ICsjZGVmaW5lIENDU0lEUl8zMl9TRVRfTUFT S8KgwqDCoCAoVUwoMHg3RkZGKSA8PCBDQ1NJRFJfMzJfU0VUX1NISUZUKQo+Pj4+Cj4+Pj4gSSBk b24ndCB0aGluayB3ZSBzaG91bGQgYmUgaW5mZXJyaW5nIGNhY2hlIHN0cnVjdHVyZSBmcm9tIHRo ZXNlIHJlZ2lzdGVyCj4+Pj4gdmFsdWVzLiBUaGUgQXJtIEFSTSBoZWxwZnVsbHkgc2F5czoKPj4+ Pgo+Pj4+IMKgwqAgfCBZb3UgY2Fubm90IG1ha2UgYW55IGluZmVyZW5jZSBhYm91dCB0aGUgYWN0 dWFsIHNpemVzIG9mIGNhY2hlcyBiYXNlZAo+Pj4+IMKgwqAgfCBvbiB0aGVzZSBwYXJhbWV0ZXJz Lgo+Pj4+Cj4+Pj4gc28gd2UgbmVlZCB0byB0YWtlIHRoZSB0b3BvbG9neSBpbmZvcm1hdGlvbiBm cm9tIGVsc2V3aGVyZS4KPj4+Pgo+Pj4KPj4+IFllYWgsIEkgYWxzbyBub3RpY2VkIHRoZSBzdGF0 ZW1lbnQgaW4gdGhlIHNwZWMuIEhvd2V2ZXIsIHRoZSBMMSBjYWNoZSBzaXplCj4+PiBmaWd1cmVk IG91dCBmcm9tIGFib3ZlIHJlZ2lzdGVycyBhcmUgbWF0Y2hpbmcgd2l0aCAibHNjcHUiIG9uIHRo ZSBtYWNoaW5lCj4+PiB3aGVyZSBJIGRpZCBteSB0ZXN0cy4gTm90ZSAibHNjcHUiIGRlcGVuZHMg b24gc3lzZnMgZW50cmllcyB3aG9zZSBpbmZvcm1hdGlvbgo+Pj4gaXMgcmV0cmlldmVkIGZyb20g QUNQSSAoUFBUVCkgdGFibGUuIFRoZSBudW1iZXIgb2YgY2FjaGUgbGV2ZWxzIGFyZSBwYXJ0aWFs bHkKPj4+IHJldHJpZXZlZCBmcm9tIHN5c3RlbSByZWdpc3RlciAoY2xpZHJfZWwxKS4KPj4+Cj4+ PiBJdCdzIGRvYWJsZSB0byByZXRyaWV2ZSB0aGUgTDEgY2FjaGUgc2l6ZSBmcm9tIEFDUEkgKFBQ VFQpIHRhYmxlLiBJJ2xsCj4+PiBjaGFuZ2UgYWNjb3JkaW5nbHkgaW4gdjIgaWYgdGhpcyBlbmFi bGVtZW50IGlzIHJlYWxseSBuZWVkZWQuIE1vcmUgY2xhcmlmeQo+Pj4gaXMgcHJvdmlkZWQgYmVs b3cuCj4+Pgo+Pj4+IEJ1dCBiZWZvcmUgd2UgZ2V0IGludG8gdGhhdCwgY2FuIHlvdSBqdXN0aWZ5 IHdoeSB3ZSBuZWVkIHRvIGRvIHRoaXMgYXQgYWxsLAo+Pj4+IHBsZWFzZT8gRG8geW91IGhhdmUg ZGF0YSB0byBzaG93IHRoZSBiZW5lZml0IG9mIGFkZGluZyB0aGlzIGNvbXBsZXhpdHk/Cj4+Pj4K Pj4+Cj4+PiBJbml0aWFsbHksIEkgZm91bmQgaXQncyB0aGUgbWlzc2VkIGZlYXR1cmUgd2hpY2gg aGFzIGJlZW4gZW5hYmxlZCBvbgo+Pj4gbWlwcy9zMzkwLiBDdXJyZW50bHksIGFsbCByZWFkLW9u bHkgYW5vbnltb3VzIFZNQXMgYXJlIGJhY2tlZCB1cCBieQo+Pj4gc2FtZSB6ZXJvIHBhZ2UuIEl0 IG1lYW5zIGFsbCByZWFkcyB0byB0aGVzZSBWTUFzIGFyZSBjYWNoZWQgYnkgc2FtZQo+Pj4gc2V0 IG9mIGNhY2hlLCBidXQgc3RpbGwgbXVsdGlwbGUgd2F5cyBpZiBzdXBwb3J0ZWQuIFNvIGl0IHdv dWxkIGJlCj4+PiBuaWNlIHRvIGhhdmUgbXVsdGlwbGUgemVybyBwYWdlcyB0byBiYWNrIHVwIHRo ZXNlIHJlYWQtb25seSBhbm9ueW1vdXMKPj4+IFZNQXMsIHNvIHRoYXQgdGhlIHJlYWRzIG9uIHRo ZW0gY2FuIGJlIGNhY2hlZCBieSBtdWx0aXBsZSBzZXRzIChtdWx0aXBsZQo+Pj4gd2F5cyBzdGls bCBpZiBzdXBwb3J0ZWQpLiBJdCdzIG92ZXJhbGwgYmVuZWZpY2lhbCB0byB0aGUgcGVyZm9ybWFu Y2UuCj4+Cj4+IElzIHRoaXMgYSBjb25jZXJuIGZvciB0cnVlIFBJUFQgY2FjaGVzLCBvciBpcyBp dCByZWFsbHkganVzdCB3b3JraW5nIGFyb3VuZCBhIHBhdGhvbG9naWNhbCBjYXNlIGZvciBhbGlh cy1kZXRlY3RpbmcgVklQVCBjYWNoZXM/Cj4+Cj4gCj4gSSB0aGluayBpdCdzIGRlZmluaXRlbHkg YSBjb25jZXJuIGZvciBQSVBUIGNhY2hlcy4gSG93ZXZlciwgSSdtIG5vdAo+IHN1cmUgYWJvdXQg VklQVCBjYWNoZXMgYmVjYXVzZSBJIGZhaWxlZCB0byB1bmRlcnN0YW5kIGhvdyBpdCB3b3Jrcwo+ IGZyb20gQVJNOC1BIHNwZWMuIElmIEknbSBjb3JyZWN0LCB0aGUgaW5kZXggb2YgVklQVCBjYWNo ZSBsaW5lIGlzCj4gc3RpbGwgZGV0ZXJtaW5lZCBieSB0aGUgcGh5c2ljYWwgYWRkcmVzcyBhbmQg dGhlIG51bWJlciBvZiBzZXRzIGlzCj4gYW5vdGhlciBsaW1pdGF0aW9uPyBGb3IgZXhhbXBsZSwg dHdvIHZpcnR1YWwgYWRkcmVzc2VzICh2MSkgYW5kICh2MikKPiBhcmUgdHJhbnNsYXRlZCB0byBz YW1lIHBoeXNpY2FsIGFkZHJlc3MgKHAxKSwgdGhlcmUgaXMgc3RpbGwgb25lCj4gY2FjaGUgbGlu ZSAoZnJvbSBwYXJ0aWN1bGFyIHNldCkgZm9yIHRoZW0uIElmIHNvLCB0aGlzIHNob3VsZCBoZWxw cwo+IGluIHRlcm1zIG9mIHBlcmZvcm1hbmNlLgo+IAo+IEhvd2V2ZXIsIEknbSBub3Qgc3VyZSBJ IHVuZGVyc3Rvb2QgVklQVCBjYWNoZXMgY29ycmVjdGx5IGJlY2F1c2UgdGhlcmUKPiBpcyBvbmUg c3RhdGVtZW50IGluIHRoZSBBUk04LUEgc3BlYyBhcyBiZWxvdy4gSXQgc2VlbXMgKHYxKSBhbmQg KHYyKQo+IGNhbiBiZSBiYWNrZWQgYnkgdHdvIGRpZmZlcmVudCBjYWNoZSBsaW5lIGZyb20gb25l IHBhcnRpY3VsYXIgc2V0Lgo+IAo+IC0tLS0KPiAKPiBUaGUgb25seSBhcmNoaXRlY3R1cmFsbHkt Z3VhcmFudGVlZCB3YXkgdG8gaW52YWxpZGF0ZSBhbGwgYWxpYXNlcyBvZgo+IGEgUEEgZnJvbSBh IFZJUFQgaW5zdHJ1Y3Rpb24gY2FjaGUgaXMgdG8gaW52YWxpZGF0ZSB0aGUgZW50aXJlIGluc3Ry dWN0aW9uCj4gY2FjaGUuCj4gCj4+PiBVbmZvcnR1bmF0ZWx5LCBJIGRpZG4ndCBmaW5kIGEgbWFj aGluZSB3aGVyZSB0aGUgc2l6ZSBvZiBjYWNoZSBzZXQgaXMKPj4+IGxhcmdlciB0aGFuIHBhZ2Ug c2l6ZS4gU28gSSBoYWQgb25lIGV4cGVyaW1lbnQgYXMgaW5kaWNhdGlvbiBob3cgTDEKPj4+IGRh dGEgY2FjaGUgbWlzcyBhZmZlY3RzIHRoZSBvdmVyYWxsIHBlcmZvcm1hbmNlOgo+Pj4KPj4+IMKg wqDCoMKgIEwxIGRhdGEgY2FjaGUgc2l6ZTrCoMKgwqDCoMKgwqDCoMKgwqDCoCAzMktCCj4+PiDC oMKgwqDCoCBMMSBkYXRhIGNhY2hlIGxpbmUgc2l6ZTrCoMKgwqDCoMKgIDY0Cj4+PiDCoMKgwqDC oCBOdW1iZXIgb2YgTDEgZGF0YSBjYWNoZSBzZXQ6wqAgNjQKPj4+IMKgwqDCoMKgIE51bWJlciBv ZiBMMSBkYXRhIGNhY2hlIHdheXM6IDgKPj4+IMKgwqDCoMKgIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPj4+IMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBzaXplID0gKGNhY2hlX2xpbmVfc2l6 ZSkgKiAobnVtX29mX3NldHMpICogKG51bV9vZl93YXlzKQo+Pj4KPj4+IMKgwqDCoMKgIEtlcm5l bCBjb25maWd1cmF0aW9uOgo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBWQV9CSVRTOsKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgNDgKPj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgUEFH RV9TSVpFOsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA0S0IKPj4+IMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgUE1EIEh1Z2VUTEIgUGFnZSBTaXplOiAyTUIKPj4+Cj4+PiDCoMKgwqDCoCBFeHBlcmlt ZW50Ogo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBJIGhhdmUgYSBwcm9ncmFtIHRvIGRvIHRo ZSBmb2xsb3dpbmcgdGhpbmdzIGFuZCBjaGVjayB0aGUKPj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgY29uc3VtZWQgdGltZSBhbmQgTDEtZGF0YS1jYWNoZS1taXNzZXMgYnkgcGVyZi4KPj4+Cj4+ PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICgxKSBBbGxvY2F0ZSAobW1hcCkgYSBQTUQgSHVnZVRM QiBQYWdlLCB3aGljaCBpcyAyTUIuCj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICgyKSBSZWFk IG9uIHRoZSBtbWFwJ2QgcmVnaW9uIGluIHN0ZXAgb2YgcGFnZSBzaXplICg0S0IpCj4+PiDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgZm9yIDggb3IgOSB0aW1lcy4gTm90ZSA4IGlzIHRo ZSBudW1iZXIgb2YgZGF0YSBjYWNoZQo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IHdheXMuCj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICgzKSBSZXBlYXQgKDIpIGZvciAxMDAw MDAwIHRpbWVzLgo+Pj4gwqDCoMKgwqAgUmVzdWx0Ogo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCAoYSkgd2hlbiB3ZSBoYXZlIDggZm9yIHRoZSBzdGVwcyBpbiAoMik6Cj4+PiDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgMzcsMTAzwqDCoMKgwqDCoCBMMS1kY2FjaGUtbG9hZC1taXNz ZXMKPj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAwLjIxNzUyMjUxNSBzZWNvbmRz IHRpbWUgZWxhcHNlZAo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDAuMjE3NTY0 MDAwIHNlY29uZHMgdXNlcgo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDAuMDAw MDAwMDAwIHNlY29uZHMgc3lzCj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIChiKSB3aGVuIHdl IGhhdmUgOSBmb3IgdGhlIHN0ZXBzIGluICgyKToKPj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCA0LDY4Nyw5MzLCoMKgIEwxLWRjYWNoZS1sb2FkLW1pc3Nlc8KgwqDCoMKgwqDCoMKg wqDCoMKgwqAgKDEyNiB0aW1lcykKPj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAw LjI0ODEzMjEwNSBzZWNvbmRzIHRpbWUgZWxhcHNlZMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAo KzE0LjIlKQo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDAuMjQ4MjY3MDAwIHNl Y29uZHMgdXNlcgo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDAuMDAwMDAwMDAw IHNlY29uZHMgc3lzCj4+Cj4+IEkgaGF2ZSBhIHZhZ3VlIGZlZWxpbmcgdGhpcyBtYXkgaGF2ZSBj b21lIHVwIGJlZm9yZSwgYnV0IGFyZSB0aGVyZSByZWFsLXdvcmxkIGFwcGxpY2F0aW9ucyB0aGF0 IGhhdmUgYSBwZXJmb3JtYW5jZSBib3R0bGVuZWNrIG9uIHJlYWRpbmcgZnJvbSB1bmluaXRpYWxp c2VkIG1lbW9yeT8gQXMgZmFyIGFzIHN5bnRoZXRpYyBiZW5jaG1hcmtzIGdvLCBJJ20gc3VyZSB3 ZSBjb3VsZCBlcXVhbGx5IGNvbWUgdXAgd2l0aCBvbmUgdGhhdCBzaG93cyBhIHJlZ3Jlc3Npb24g ZHVlIHRvIHJlYWwgZGF0YSBiZWluZyBwdXNoZWQgb3V0IG9mIHRoZSBjYWNoZSBieSBhbGwgdGhv c2UgZXh0cmEgemVyb3MgOykKPiAKPiBbLi4uXQo+IAo+IE9rLiBJZiB0aGlzIHdhcyBwcm9wb3Nl ZCBiZWZvcmUsIEknbSBub3Qgc3VyZSBpZiB0aGUgbGluayB0byB0aGF0Cj4gcGF0Y2hzZXQgaXMg c3RpbGwgYXZhaWxhYmxlPyA6KQo+IAo+IFdoZW4gSSB3YXMgc2VhcmNoaW5nICJteV96ZXJvX3Bm biIgaW4gdXBzdHJlYW0ga2VybmVsLCBEQVggdXNlcyB0aGUKPiB6ZXJvIHBhZ2VzIHRvIGZpbGwg dGhlIGhvbGVzIGluIG9uZSBwYXJ0aWN1bGFyIGZpbGUgaW4gZGF4X2xvYWRfaG9sZSgpLgo+IG1t YXAoKSBvbiAvcHJvYy9rY29yZSBjb3VsZCB1c2UgemVybyBwYWdlIGVpdGhlci4KCkJ1dCBob3cg b2Z0ZW4gdGhvc2UgbWFwcGVkIGFyZWFzIHdpbGwgYmUgdXNlZCBhZnRlcndhcmRzIGVpdGhlciBp biBEQVgKb3IgL3Byb2Mva2NvcmUgPyBJdCBzZWVtcyBsaWtlIHRoZSBtaW5pbWFsIGFkYXB0aW9u IGZvciB0aGlzIGZlYXR1cmUgc28KZmFyIG9uIHBsYXRmb3JtcyAoaS5lIHMzOTAgYW5kIG1pcHMp IG1pZ2h0IGhhdmUgdG8gZG8gd2l0aCByZWFsIHdvcmxkCndvcmtsb2FkJ3MgZnJlcXVlbmN5IG9m IHN1Y2ggcmVhZCBhY2Nlc3NlcyBvbiBtYXBwZWQgYXJlYXMgdXNpbmcgemVybwpwYWdlcy4KCj4g Cj4gWWVzLCBpdCdzIGNvcnJlY3QgdGhhdCB0aGUgZGF0YSBjYWNoZSBoYXMgbW9yZSBjaGFuY2Ug dG8gYmUgZmx1c2hlZCBieQo+IHRoZXNlIGV4dHJhIHplcm9lcy4gSG93ZXZlciwgaXQncyBub3Qg d2h5IHdlIGNvbXByb21pc2UgdGhlIHBlcmZvcm1hbmNlCj4gb24gcmVhZGluZyB6ZXJvIHBhZ2Ug YW5kIGRlcHJlc3MgaXQgaW50ZW50aW9uYWxseS4gVGhlIGNhY2hlIGxpbmVzIHdvbid0Cj4gYmUg dXNlZCBpZiB0aGVyZSBpcyBubyByZWFkaW5nIGFjdGl2aXRpZXMgb24gemVybyBwYWdlIDopCj4g Cj4gQ2hlZXJzLAo+IEdhdmluCj4gCj4gwqAKPiAKPiAKCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0Cmxp bnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFk Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK 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 X-Spam-Level: X-Spam-Status: No, score=-11.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0D1BFC43464 for ; Mon, 21 Sep 2020 12:41:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C048C20EDD for ; Mon, 21 Sep 2020 12:41:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726641AbgIUMlR (ORCPT ); Mon, 21 Sep 2020 08:41:17 -0400 Received: from foss.arm.com ([217.140.110.172]:42584 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726341AbgIUMlR (ORCPT ); Mon, 21 Sep 2020 08:41:17 -0400 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 1F2EED6E; Mon, 21 Sep 2020 05:41:16 -0700 (PDT) Received: from [10.163.75.158] (unknown [10.163.75.158]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C0AA83F73B; Mon, 21 Sep 2020 05:41:13 -0700 (PDT) Subject: Re: [PATCH 2/2] arm64/mm: Enable color zero pages To: Gavin Shan , Robin Murphy , Will Deacon Cc: mark.rutland@arm.com, catalin.marinas@arm.com, linux-kernel@vger.kernel.org, shan.gavin@gmail.com, linux-arm-kernel@lists.infradead.org References: <20200916032523.13011-1-gshan@redhat.com> <20200916032523.13011-3-gshan@redhat.com> <20200916082819.GB27496@willie-the-truck> <33e9a04e-9f93-6a06-273d-284900bc1535@arm.com> <968a5ae7-ebed-8191-15df-6c9860dc72fe@redhat.com> From: Anshuman Khandual Message-ID: Date: Mon, 21 Sep 2020 18:10:33 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <968a5ae7-ebed-8191-15df-6c9860dc72fe@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/21/2020 08:26 AM, Gavin Shan wrote: > Hi Robin, > > On 9/17/20 8:22 PM, Robin Murphy wrote: >> On 2020-09-17 04:35, Gavin Shan wrote: >>> On 9/16/20 6:28 PM, Will Deacon wrote: >>>> On Wed, Sep 16, 2020 at 01:25:23PM +1000, Gavin Shan wrote: >>>>> This enables color zero pages by allocating contigous page frames >>>>> for it. The number of pages for this is determined by L1 dCache >>>>> (or iCache) size, which is probbed from the hardware. >>>>> >>>>>     * Add cache_total_size() to return L1 dCache (or iCache) size >>>>> >>>>>     * Implement setup_zero_pages(), which is called after the page >>>>>       allocator begins to work, to allocate the contigous pages >>>>>       needed by color zero page. >>>>> >>>>>     * Reworked ZERO_PAGE() and define __HAVE_COLOR_ZERO_PAGE. >>>>> >>>>> Signed-off-by: Gavin Shan >>>>> --- >>>>>   arch/arm64/include/asm/cache.h   | 22 ++++++++++++++++++++ >>>>>   arch/arm64/include/asm/pgtable.h |  9 ++++++-- >>>>>   arch/arm64/kernel/cacheinfo.c    | 34 +++++++++++++++++++++++++++++++ >>>>>   arch/arm64/mm/init.c             | 35 ++++++++++++++++++++++++++++++++ >>>>>   arch/arm64/mm/mmu.c              |  7 ------- >>>>>   5 files changed, 98 insertions(+), 9 deletions(-) >>>>> >>>>> diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h >>>>> index a4d1b5f771f6..420e9dde2c51 100644 >>>>> --- a/arch/arm64/include/asm/cache.h >>>>> +++ b/arch/arm64/include/asm/cache.h >>>>> @@ -39,6 +39,27 @@ >>>>>   #define CLIDR_LOC(clidr)    (((clidr) >> CLIDR_LOC_SHIFT) & 0x7) >>>>>   #define CLIDR_LOUIS(clidr)    (((clidr) >> CLIDR_LOUIS_SHIFT) & 0x7) >>>>> +#define CSSELR_TND_SHIFT    4 >>>>> +#define CSSELR_TND_MASK        (UL(1) << CSSELR_TND_SHIFT) >>>>> +#define CSSELR_LEVEL_SHIFT    1 >>>>> +#define CSSELR_LEVEL_MASK    (UL(7) << CSSELR_LEVEL_SHIFT) >>>>> +#define CSSELR_IND_SHIFT    0 >>>>> +#define CSSERL_IND_MASK        (UL(1) << CSSELR_IND_SHIFT) >>>>> + >>>>> +#define CCSIDR_64_LS_SHIFT    0 >>>>> +#define CCSIDR_64_LS_MASK    (UL(7) << CCSIDR_64_LS_SHIFT) >>>>> +#define CCSIDR_64_ASSOC_SHIFT    3 >>>>> +#define CCSIDR_64_ASSOC_MASK    (UL(0x1FFFFF) << CCSIDR_64_ASSOC_SHIFT) >>>>> +#define CCSIDR_64_SET_SHIFT    32 >>>>> +#define CCSIDR_64_SET_MASK    (UL(0xFFFFFF) << CCSIDR_64_SET_SHIFT) >>>>> + >>>>> +#define CCSIDR_32_LS_SHIFT    0 >>>>> +#define CCSIDR_32_LS_MASK    (UL(7) << CCSIDR_32_LS_SHIFT) >>>>> +#define CCSIDR_32_ASSOC_SHIFT    3 >>>>> +#define CCSIDR_32_ASSOC_MASK    (UL(0x3FF) << CCSIDR_32_ASSOC_SHIFT) >>>>> +#define CCSIDR_32_SET_SHIFT    13 >>>>> +#define CCSIDR_32_SET_MASK    (UL(0x7FFF) << CCSIDR_32_SET_SHIFT) >>>> >>>> I don't think we should be inferring cache structure from these register >>>> values. The Arm ARM helpfully says: >>>> >>>>    | You cannot make any inference about the actual sizes of caches based >>>>    | on these parameters. >>>> >>>> so we need to take the topology information from elsewhere. >>>> >>> >>> Yeah, I also noticed the statement in the spec. However, the L1 cache size >>> figured out from above registers are matching with "lscpu" on the machine >>> where I did my tests. Note "lscpu" depends on sysfs entries whose information >>> is retrieved from ACPI (PPTT) table. The number of cache levels are partially >>> retrieved from system register (clidr_el1). >>> >>> It's doable to retrieve the L1 cache size from ACPI (PPTT) table. I'll >>> change accordingly in v2 if this enablement is really needed. More clarify >>> is provided below. >>> >>>> But before we get into that, can you justify why we need to do this at all, >>>> please? Do you have data to show the benefit of adding this complexity? >>>> >>> >>> Initially, I found it's the missed feature which has been enabled on >>> mips/s390. Currently, all read-only anonymous VMAs are backed up by >>> same zero page. It means all reads to these VMAs are cached by same >>> set of cache, but still multiple ways if supported. So it would be >>> nice to have multiple zero pages to back up these read-only anonymous >>> VMAs, so that the reads on them can be cached by multiple sets (multiple >>> ways still if supported). It's overall beneficial to the performance. >> >> Is this a concern for true PIPT caches, or is it really just working around a pathological case for alias-detecting VIPT caches? >> > > I think it's definitely a concern for PIPT caches. However, I'm not > sure about VIPT caches because I failed to understand how it works > from ARM8-A spec. If I'm correct, the index of VIPT cache line is > still determined by the physical address and the number of sets is > another limitation? For example, two virtual addresses (v1) and (v2) > are translated to same physical address (p1), there is still one > cache line (from particular set) for them. If so, this should helps > in terms of performance. > > However, I'm not sure I understood VIPT caches correctly because there > is one statement in the ARM8-A spec as below. It seems (v1) and (v2) > can be backed by two different cache line from one particular set. > > ---- > > The only architecturally-guaranteed way to invalidate all aliases of > a PA from a VIPT instruction cache is to invalidate the entire instruction > cache. > >>> Unfortunately, I didn't find a machine where the size of cache set is >>> larger than page size. So I had one experiment as indication how L1 >>> data cache miss affects the overall performance: >>> >>>      L1 data cache size:           32KB >>>      L1 data cache line size:      64 >>>      Number of L1 data cache set:  64 >>>      Number of L1 data cache ways: 8 >>>      ---------------------------------------------------------------------- >>>                    size = (cache_line_size) * (num_of_sets) * (num_of_ways) >>> >>>      Kernel configuration: >>>             VA_BITS:               48 >>>             PAGE_SIZE:             4KB >>>             PMD HugeTLB Page Size: 2MB >>> >>>      Experiment: >>>             I have a program to do the following things and check the >>>             consumed time and L1-data-cache-misses by perf. >>> >>>             (1) Allocate (mmap) a PMD HugeTLB Page, which is 2MB. >>>             (2) Read on the mmap'd region in step of page size (4KB) >>>                 for 8 or 9 times. Note 8 is the number of data cache >>>                 ways. >>>             (3) Repeat (2) for 1000000 times. >>>      Result: >>>             (a) when we have 8 for the steps in (2): >>>                 37,103      L1-dcache-load-misses >>>                 0.217522515 seconds time elapsed >>>                 0.217564000 seconds user >>>                 0.000000000 seconds sys >>>             (b) when we have 9 for the steps in (2): >>>                 4,687,932   L1-dcache-load-misses            (126 times) >>>                 0.248132105 seconds time elapsed             (+14.2%) >>>                 0.248267000 seconds user >>>                 0.000000000 seconds sys >> >> I have a vague feeling this may have come up before, but are there real-world applications that have a performance bottleneck on reading from uninitialised memory? As far as synthetic benchmarks go, I'm sure we could equally come up with one that shows a regression due to real data being pushed out of the cache by all those extra zeros ;) > > [...] > > Ok. If this was proposed before, I'm not sure if the link to that > patchset is still available? :) > > When I was searching "my_zero_pfn" in upstream kernel, DAX uses the > zero pages to fill the holes in one particular file in dax_load_hole(). > mmap() on /proc/kcore could use zero page either. But how often those mapped areas will be used afterwards either in DAX or /proc/kcore ? It seems like the minimal adaption for this feature so far on platforms (i.e s390 and mips) might have to do with real world workload's frequency of such read accesses on mapped areas using zero pages. > > Yes, it's correct that the data cache has more chance to be flushed by > these extra zeroes. However, it's not why we compromise the performance > on reading zero page and depress it intentionally. The cache lines won't > be used if there is no reading activities on zero page :) > > Cheers, > Gavin > >   > >