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.8 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 F32DDC43463 for ; Mon, 21 Sep 2020 02:58:37 +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 85DF320795 for ; Mon, 21 Sep 2020 02:58:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="tnWAW1gd"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="UNYinvlQ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 85DF320795 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.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-Type: Content-Transfer-Encoding:Cc:Reply-To:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=PXGrwym2WXqUIK3g1O7fyyvDtu3KUcQbpr3X83kuBkE=; b=tnWAW1gdORQ1Pc r2GhCiiFVREBxIwMLvkTqUN07J8Z73wolk5m1zXppzrltc+KqI0O3NN5PGJevtreUSrwgaMjY0/0k IXUt0l7cp0T/swx9MSBEVVRFqxELX+1Zkwddi506YYCDSxo3ScAzt5sXj5LjjJ9QHiGEfnKE/jxZO GacFbOTM4V5gADZBYRU0dBllZuiNJKNFRKljA1FPEGPYN26E0oVxfbGEerXAsDtfPT7+DQahAcxMq yD6a9pRDR7qaGTzEprYoowdeCyTYZfq4ws8/voLiI0A2MY7NmpfRn5eqjZxzdSDEFpI7t5sC/24Cb wDJ/2mO6qvEXuzUwkL7A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kKC0m-0002gl-MO; Mon, 21 Sep 2020 02:57:04 +0000 Received: from us-smtp-2.mimecast.com ([205.139.110.61] helo=us-smtp-delivery-1.mimecast.com) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kKC0j-0002gK-Up for linux-arm-kernel@lists.infradead.org; Mon, 21 Sep 2020 02:57:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1600657020; h=from:from:reply-to: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=YeKw+/y7Dc2RU9VjLNTsXLBHSQ9qLyRYCz78WrOYT30=; b=UNYinvlQjwfskOy4F4KiP4Vd+1Qb8GuElSTNVc6l4W1NDoMdKqiYvsjp3MiAWt4bM+ha06 y/oxwrzlvP37LN6tb3rRfr2/j5GcK+atvQUG3sxkBQ0tPX8VE4z4SQEdp1bU3Lbbz3hh5F +pugu3odp+hInyWP85BqZLV4ENAaFXA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-370-7Gw7oaaNPXi57DyeyO4ITw-1; Sun, 20 Sep 2020 22:56:55 -0400 X-MC-Unique: 7Gw7oaaNPXi57DyeyO4ITw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 47D111005E5B; Mon, 21 Sep 2020 02:56:54 +0000 (UTC) Received: from [10.64.54.34] (vpn2-54-34.bne.redhat.com [10.64.54.34]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C6B495D9D5; Mon, 21 Sep 2020 02:56:51 +0000 (UTC) Subject: Re: [PATCH 2/2] arm64/mm: Enable color zero pages To: 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> From: Gavin Shan Message-ID: <968a5ae7-ebed-8191-15df-6c9860dc72fe@redhat.com> Date: Mon, 21 Sep 2020 12:56:47 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0 MIME-Version: 1.0 In-Reply-To: <33e9a04e-9f93-6a06-273d-284900bc1535@arm.com> Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200920_225702_026630_BCA43B08 X-CRM114-Status: GOOD ( 36.86 ) 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: , Reply-To: Gavin Shan Cc: mark.rutland@arm.com, anshuman.khandual@arm.com, catalin.marinas@arm.com, linux-kernel@vger.kernel.org, shan.gavin@gmail.com, linux-arm-kernel@lists.infradead.org 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 SGkgUm9iaW4sCgpPbiA5LzE3LzIwIDg6MjIgUE0sIFJvYmluIE11cnBoeSB3cm90ZToKPiBPbiAy MDIwLTA5LTE3IDA0OjM1LCBHYXZpbiBTaGFuIHdyb3RlOgo+PiBPbiA5LzE2LzIwIDY6MjggUE0s IFdpbGwgRGVhY29uIHdyb3RlOgo+Pj4gT24gV2VkLCBTZXAgMTYsIDIwMjAgYXQgMDE6MjU6MjNQ TSArMTAwMCwgR2F2aW4gU2hhbiB3cm90ZToKPj4+PiBUaGlzIGVuYWJsZXMgY29sb3IgemVybyBw YWdlcyBieSBhbGxvY2F0aW5nIGNvbnRpZ291cyBwYWdlIGZyYW1lcwo+Pj4+IGZvciBpdC4gVGhl IG51bWJlciBvZiBwYWdlcyBmb3IgdGhpcyBpcyBkZXRlcm1pbmVkIGJ5IEwxIGRDYWNoZQo+Pj4+ IChvciBpQ2FjaGUpIHNpemUsIHdoaWNoIGlzIHByb2JiZWQgZnJvbSB0aGUgaGFyZHdhcmUuCj4+ Pj4KPj4+PiDCoMKgwqAgKiBBZGQgY2FjaGVfdG90YWxfc2l6ZSgpIHRvIHJldHVybiBMMSBkQ2Fj aGUgKG9yIGlDYWNoZSkgc2l6ZQo+Pj4+Cj4+Pj4gwqDCoMKgICogSW1wbGVtZW50IHNldHVwX3pl cm9fcGFnZXMoKSwgd2hpY2ggaXMgY2FsbGVkIGFmdGVyIHRoZSBwYWdlCj4+Pj4gwqDCoMKgwqDC oCBhbGxvY2F0b3IgYmVnaW5zIHRvIHdvcmssIHRvIGFsbG9jYXRlIHRoZSBjb250aWdvdXMgcGFn ZXMKPj4+PiDCoMKgwqDCoMKgIG5lZWRlZCBieSBjb2xvciB6ZXJvIHBhZ2UuCj4+Pj4KPj4+PiDC oMKgwqAgKiBSZXdvcmtlZCBaRVJPX1BBR0UoKSBhbmQgZGVmaW5lIF9fSEFWRV9DT0xPUl9aRVJP X1BBR0UuCj4+Pj4KPj4+PiBTaWduZWQtb2ZmLWJ5OiBHYXZpbiBTaGFuIDxnc2hhbkByZWRoYXQu Y29tPgo+Pj4+IC0tLQo+Pj4+IMKgIGFyY2gvYXJtNjQvaW5jbHVkZS9hc20vY2FjaGUuaMKgwqAg fCAyMiArKysrKysrKysrKysrKysrKysrKwo+Pj4+IMKgIGFyY2gvYXJtNjQvaW5jbHVkZS9hc20v cGd0YWJsZS5oIHzCoCA5ICsrKysrKy0tCj4+Pj4gwqAgYXJjaC9hcm02NC9rZXJuZWwvY2FjaGVp bmZvLmPCoMKgwqAgfCAzNCArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCj4+Pj4gwqAg YXJjaC9hcm02NC9tbS9pbml0LmPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfCAzNSArKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKwo+Pj4+IMKgIGFyY2gvYXJtNjQvbW0vbW11LmPCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqAgNyAtLS0tLS0tCj4+Pj4gwqAgNSBmaWxlcyBjaGFu Z2VkLCA5OCBpbnNlcnRpb25zKCspLCA5IGRlbGV0aW9ucygtKQo+Pj4+Cj4+Pj4gZGlmZiAtLWdp dCBhL2FyY2gvYXJtNjQvaW5jbHVkZS9hc20vY2FjaGUuaCBiL2FyY2gvYXJtNjQvaW5jbHVkZS9h c20vY2FjaGUuaAo+Pj4+IGluZGV4IGE0ZDFiNWY3NzFmNi4uNDIwZTlkZGUyYzUxIDEwMDY0NAo+ Pj4+IC0tLSBhL2FyY2gvYXJtNjQvaW5jbHVkZS9hc20vY2FjaGUuaAo+Pj4+ICsrKyBiL2FyY2gv YXJtNjQvaW5jbHVkZS9hc20vY2FjaGUuaAo+Pj4+IEBAIC0zOSw2ICszOSwyNyBAQAo+Pj4+IMKg ICNkZWZpbmUgQ0xJRFJfTE9DKGNsaWRyKcKgwqDCoCAoKChjbGlkcikgPj4gQ0xJRFJfTE9DX1NI SUZUKSAmIDB4NykKPj4+PiDCoCAjZGVmaW5lIENMSURSX0xPVUlTKGNsaWRyKcKgwqDCoCAoKChj bGlkcikgPj4gQ0xJRFJfTE9VSVNfU0hJRlQpICYgMHg3KQo+Pj4+ICsjZGVmaW5lIENTU0VMUl9U TkRfU0hJRlTCoMKgwqAgNAo+Pj4+ICsjZGVmaW5lIENTU0VMUl9UTkRfTUFTS8KgwqDCoMKgwqDC oMKgIChVTCgxKSA8PCBDU1NFTFJfVE5EX1NISUZUKQo+Pj4+ICsjZGVmaW5lIENTU0VMUl9MRVZF TF9TSElGVMKgwqDCoCAxCj4+Pj4gKyNkZWZpbmUgQ1NTRUxSX0xFVkVMX01BU0vCoMKgwqAgKFVM KDcpIDw8IENTU0VMUl9MRVZFTF9TSElGVCkKPj4+PiArI2RlZmluZSBDU1NFTFJfSU5EX1NISUZU wqDCoMKgIDAKPj4+PiArI2RlZmluZSBDU1NFUkxfSU5EX01BU0vCoMKgwqDCoMKgwqDCoCAoVUwo MSkgPDwgQ1NTRUxSX0lORF9TSElGVCkKPj4+PiArCj4+Pj4gKyNkZWZpbmUgQ0NTSURSXzY0X0xT X1NISUZUwqDCoMKgIDAKPj4+PiArI2RlZmluZSBDQ1NJRFJfNjRfTFNfTUFTS8KgwqDCoCAoVUwo NykgPDwgQ0NTSURSXzY0X0xTX1NISUZUKQo+Pj4+ICsjZGVmaW5lIENDU0lEUl82NF9BU1NPQ19T SElGVMKgwqDCoCAzCj4+Pj4gKyNkZWZpbmUgQ0NTSURSXzY0X0FTU09DX01BU0vCoMKgwqAgKFVM KDB4MUZGRkZGKSA8PCBDQ1NJRFJfNjRfQVNTT0NfU0hJRlQpCj4+Pj4gKyNkZWZpbmUgQ0NTSURS XzY0X1NFVF9TSElGVMKgwqDCoCAzMgo+Pj4+ICsjZGVmaW5lIENDU0lEUl82NF9TRVRfTUFTS8Kg wqDCoCAoVUwoMHhGRkZGRkYpIDw8IENDU0lEUl82NF9TRVRfU0hJRlQpCj4+Pj4gKwo+Pj4+ICsj ZGVmaW5lIENDU0lEUl8zMl9MU19TSElGVMKgwqDCoCAwCj4+Pj4gKyNkZWZpbmUgQ0NTSURSXzMy X0xTX01BU0vCoMKgwqAgKFVMKDcpIDw8IENDU0lEUl8zMl9MU19TSElGVCkKPj4+PiArI2RlZmlu ZSBDQ1NJRFJfMzJfQVNTT0NfU0hJRlTCoMKgwqAgMwo+Pj4+ICsjZGVmaW5lIENDU0lEUl8zMl9B U1NPQ19NQVNLwqDCoMKgIChVTCgweDNGRikgPDwgQ0NTSURSXzMyX0FTU09DX1NISUZUKQo+Pj4+ ICsjZGVmaW5lIENDU0lEUl8zMl9TRVRfU0hJRlTCoMKgwqAgMTMKPj4+PiArI2RlZmluZSBDQ1NJ RFJfMzJfU0VUX01BU0vCoMKgwqAgKFVMKDB4N0ZGRikgPDwgQ0NTSURSXzMyX1NFVF9TSElGVCkK Pj4+Cj4+PiBJIGRvbid0IHRoaW5rIHdlIHNob3VsZCBiZSBpbmZlcnJpbmcgY2FjaGUgc3RydWN0 dXJlIGZyb20gdGhlc2UgcmVnaXN0ZXIKPj4+IHZhbHVlcy4gVGhlIEFybSBBUk0gaGVscGZ1bGx5 IHNheXM6Cj4+Pgo+Pj4gwqDCoCB8IFlvdSBjYW5ub3QgbWFrZSBhbnkgaW5mZXJlbmNlIGFib3V0 IHRoZSBhY3R1YWwgc2l6ZXMgb2YgY2FjaGVzIGJhc2VkCj4+PiDCoMKgIHwgb24gdGhlc2UgcGFy YW1ldGVycy4KPj4+Cj4+PiBzbyB3ZSBuZWVkIHRvIHRha2UgdGhlIHRvcG9sb2d5IGluZm9ybWF0 aW9uIGZyb20gZWxzZXdoZXJlLgo+Pj4KPj4KPj4gWWVhaCwgSSBhbHNvIG5vdGljZWQgdGhlIHN0 YXRlbWVudCBpbiB0aGUgc3BlYy4gSG93ZXZlciwgdGhlIEwxIGNhY2hlIHNpemUKPj4gZmlndXJl ZCBvdXQgZnJvbSBhYm92ZSByZWdpc3RlcnMgYXJlIG1hdGNoaW5nIHdpdGggImxzY3B1IiBvbiB0 aGUgbWFjaGluZQo+PiB3aGVyZSBJIGRpZCBteSB0ZXN0cy4gTm90ZSAibHNjcHUiIGRlcGVuZHMg b24gc3lzZnMgZW50cmllcyB3aG9zZSBpbmZvcm1hdGlvbgo+PiBpcyByZXRyaWV2ZWQgZnJvbSBB Q1BJIChQUFRUKSB0YWJsZS4gVGhlIG51bWJlciBvZiBjYWNoZSBsZXZlbHMgYXJlIHBhcnRpYWxs eQo+PiByZXRyaWV2ZWQgZnJvbSBzeXN0ZW0gcmVnaXN0ZXIgKGNsaWRyX2VsMSkuCj4+Cj4+IEl0 J3MgZG9hYmxlIHRvIHJldHJpZXZlIHRoZSBMMSBjYWNoZSBzaXplIGZyb20gQUNQSSAoUFBUVCkg dGFibGUuIEknbGwKPj4gY2hhbmdlIGFjY29yZGluZ2x5IGluIHYyIGlmIHRoaXMgZW5hYmxlbWVu dCBpcyByZWFsbHkgbmVlZGVkLiBNb3JlIGNsYXJpZnkKPj4gaXMgcHJvdmlkZWQgYmVsb3cuCj4+ Cj4+PiBCdXQgYmVmb3JlIHdlIGdldCBpbnRvIHRoYXQsIGNhbiB5b3UganVzdGlmeSB3aHkgd2Ug bmVlZCB0byBkbyB0aGlzIGF0IGFsbCwKPj4+IHBsZWFzZT8gRG8geW91IGhhdmUgZGF0YSB0byBz aG93IHRoZSBiZW5lZml0IG9mIGFkZGluZyB0aGlzIGNvbXBsZXhpdHk/Cj4+Pgo+Pgo+PiBJbml0 aWFsbHksIEkgZm91bmQgaXQncyB0aGUgbWlzc2VkIGZlYXR1cmUgd2hpY2ggaGFzIGJlZW4gZW5h YmxlZCBvbgo+PiBtaXBzL3MzOTAuIEN1cnJlbnRseSwgYWxsIHJlYWQtb25seSBhbm9ueW1vdXMg Vk1BcyBhcmUgYmFja2VkIHVwIGJ5Cj4+IHNhbWUgemVybyBwYWdlLiBJdCBtZWFucyBhbGwgcmVh ZHMgdG8gdGhlc2UgVk1BcyBhcmUgY2FjaGVkIGJ5IHNhbWUKPj4gc2V0IG9mIGNhY2hlLCBidXQg c3RpbGwgbXVsdGlwbGUgd2F5cyBpZiBzdXBwb3J0ZWQuIFNvIGl0IHdvdWxkIGJlCj4+IG5pY2Ug dG8gaGF2ZSBtdWx0aXBsZSB6ZXJvIHBhZ2VzIHRvIGJhY2sgdXAgdGhlc2UgcmVhZC1vbmx5IGFu b255bW91cwo+PiBWTUFzLCBzbyB0aGF0IHRoZSByZWFkcyBvbiB0aGVtIGNhbiBiZSBjYWNoZWQg YnkgbXVsdGlwbGUgc2V0cyAobXVsdGlwbGUKPj4gd2F5cyBzdGlsbCBpZiBzdXBwb3J0ZWQpLiBJ dCdzIG92ZXJhbGwgYmVuZWZpY2lhbCB0byB0aGUgcGVyZm9ybWFuY2UuCj4gCj4gSXMgdGhpcyBh IGNvbmNlcm4gZm9yIHRydWUgUElQVCBjYWNoZXMsIG9yIGlzIGl0IHJlYWxseSBqdXN0IHdvcmtp bmcgYXJvdW5kIGEgcGF0aG9sb2dpY2FsIGNhc2UgZm9yIGFsaWFzLWRldGVjdGluZyBWSVBUIGNh Y2hlcz8KPiAKCkkgdGhpbmsgaXQncyBkZWZpbml0ZWx5IGEgY29uY2VybiBmb3IgUElQVCBjYWNo ZXMuIEhvd2V2ZXIsIEknbSBub3QKc3VyZSBhYm91dCBWSVBUIGNhY2hlcyBiZWNhdXNlIEkgZmFp bGVkIHRvIHVuZGVyc3RhbmQgaG93IGl0IHdvcmtzCmZyb20gQVJNOC1BIHNwZWMuIElmIEknbSBj b3JyZWN0LCB0aGUgaW5kZXggb2YgVklQVCBjYWNoZSBsaW5lIGlzCnN0aWxsIGRldGVybWluZWQg YnkgdGhlIHBoeXNpY2FsIGFkZHJlc3MgYW5kIHRoZSBudW1iZXIgb2Ygc2V0cyBpcwphbm90aGVy IGxpbWl0YXRpb24/IEZvciBleGFtcGxlLCB0d28gdmlydHVhbCBhZGRyZXNzZXMgKHYxKSBhbmQg KHYyKQphcmUgdHJhbnNsYXRlZCB0byBzYW1lIHBoeXNpY2FsIGFkZHJlc3MgKHAxKSwgdGhlcmUg aXMgc3RpbGwgb25lCmNhY2hlIGxpbmUgKGZyb20gcGFydGljdWxhciBzZXQpIGZvciB0aGVtLiBJ ZiBzbywgdGhpcyBzaG91bGQgaGVscHMKaW4gdGVybXMgb2YgcGVyZm9ybWFuY2UuCgpIb3dldmVy LCBJJ20gbm90IHN1cmUgSSB1bmRlcnN0b29kIFZJUFQgY2FjaGVzIGNvcnJlY3RseSBiZWNhdXNl IHRoZXJlCmlzIG9uZSBzdGF0ZW1lbnQgaW4gdGhlIEFSTTgtQSBzcGVjIGFzIGJlbG93LiBJdCBz ZWVtcyAodjEpIGFuZCAodjIpCmNhbiBiZSBiYWNrZWQgYnkgdHdvIGRpZmZlcmVudCBjYWNoZSBs aW5lIGZyb20gb25lIHBhcnRpY3VsYXIgc2V0LgoKLS0tLQoKVGhlIG9ubHkgYXJjaGl0ZWN0dXJh bGx5LWd1YXJhbnRlZWQgd2F5IHRvIGludmFsaWRhdGUgYWxsIGFsaWFzZXMgb2YKYSBQQSBmcm9t IGEgVklQVCBpbnN0cnVjdGlvbiBjYWNoZSBpcyB0byBpbnZhbGlkYXRlIHRoZSBlbnRpcmUgaW5z dHJ1Y3Rpb24KY2FjaGUuCgo+PiBVbmZvcnR1bmF0ZWx5LCBJIGRpZG4ndCBmaW5kIGEgbWFjaGlu ZSB3aGVyZSB0aGUgc2l6ZSBvZiBjYWNoZSBzZXQgaXMKPj4gbGFyZ2VyIHRoYW4gcGFnZSBzaXpl LiBTbyBJIGhhZCBvbmUgZXhwZXJpbWVudCBhcyBpbmRpY2F0aW9uIGhvdyBMMQo+PiBkYXRhIGNh Y2hlIG1pc3MgYWZmZWN0cyB0aGUgb3ZlcmFsbCBwZXJmb3JtYW5jZToKPj4KPj4gwqDCoMKgwqAg TDEgZGF0YSBjYWNoZSBzaXplOsKgwqDCoMKgwqDCoMKgwqDCoMKgIDMyS0IKPj4gwqDCoMKgwqAg TDEgZGF0YSBjYWNoZSBsaW5lIHNpemU6wqDCoMKgwqDCoCA2NAo+PiDCoMKgwqDCoCBOdW1iZXIg b2YgTDEgZGF0YSBjYWNoZSBzZXQ6wqAgNjQKPj4gwqDCoMKgwqAgTnVtYmVyIG9mIEwxIGRhdGEg Y2FjaGUgd2F5czogOAo+PiDCoMKgwqDCoCAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4+IMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBzaXplID0gKGNhY2hlX2xpbmVfc2l6ZSkgKiAobnVtX29m X3NldHMpICogKG51bV9vZl93YXlzKQo+Pgo+PiDCoMKgwqDCoCBLZXJuZWwgY29uZmlndXJhdGlv bjoKPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBWQV9CSVRTOsKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgNDgKPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBQQUdFX1NJWkU6wqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIDRLQgo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFBNRCBIdWdlVExC IFBhZ2UgU2l6ZTogMk1CCj4+Cj4+IMKgwqDCoMKgIEV4cGVyaW1lbnQ6Cj4+IMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgSSBoYXZlIGEgcHJvZ3JhbSB0byBkbyB0aGUgZm9sbG93aW5nIHRoaW5ncyBh bmQgY2hlY2sgdGhlCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgY29uc3VtZWQgdGltZSBhbmQg TDEtZGF0YS1jYWNoZS1taXNzZXMgYnkgcGVyZi4KPj4KPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCAoMSkgQWxsb2NhdGUgKG1tYXApIGEgUE1EIEh1Z2VUTEIgUGFnZSwgd2hpY2ggaXMgMk1CLgo+ PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICgyKSBSZWFkIG9uIHRoZSBtbWFwJ2QgcmVnaW9uIGlu IHN0ZXAgb2YgcGFnZSBzaXplICg0S0IpCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCBmb3IgOCBvciA5IHRpbWVzLiBOb3RlIDggaXMgdGhlIG51bWJlciBvZiBkYXRhIGNhY2hlCj4+ IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB3YXlzLgo+PiDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgICgzKSBSZXBlYXQgKDIpIGZvciAxMDAwMDAwIHRpbWVzLgo+PiDCoMKgwqDCoCBSZXN1 bHQ6Cj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKGEpIHdoZW4gd2UgaGF2ZSA4IGZvciB0aGUg c3RlcHMgaW4gKDIpOgo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgMzcsMTAzwqDC oMKgwqDCoCBMMS1kY2FjaGUtbG9hZC1taXNzZXMKPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIDAuMjE3NTIyNTE1IHNlY29uZHMgdGltZSBlbGFwc2VkCj4+IMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCAwLjIxNzU2NDAwMCBzZWNvbmRzIHVzZXIKPj4gwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIDAuMDAwMDAwMDAwIHNlY29uZHMgc3lzCj4+IMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgKGIpIHdoZW4gd2UgaGF2ZSA5IGZvciB0aGUgc3RlcHMgaW4gKDIpOgo+PiDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgNCw2ODcsOTMywqDCoCBMMS1kY2FjaGUtbG9h ZC1taXNzZXPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICgxMjYgdGltZXMpCj4+IMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCAwLjI0ODEzMjEwNSBzZWNvbmRzIHRpbWUgZWxhcHNlZMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCAoKzE0LjIlKQo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgMC4yNDgyNjcwMDAgc2Vjb25kcyB1c2VyCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCAwLjAwMDAwMDAwMCBzZWNvbmRzIHN5cwo+IAo+IEkgaGF2ZSBhIHZhZ3VlIGZlZWxp bmcgdGhpcyBtYXkgaGF2ZSBjb21lIHVwIGJlZm9yZSwgYnV0IGFyZSB0aGVyZSByZWFsLXdvcmxk IGFwcGxpY2F0aW9ucyB0aGF0IGhhdmUgYSBwZXJmb3JtYW5jZSBib3R0bGVuZWNrIG9uIHJlYWRp bmcgZnJvbSB1bmluaXRpYWxpc2VkIG1lbW9yeT8gQXMgZmFyIGFzIHN5bnRoZXRpYyBiZW5jaG1h cmtzIGdvLCBJJ20gc3VyZSB3ZSBjb3VsZCBlcXVhbGx5IGNvbWUgdXAgd2l0aCBvbmUgdGhhdCBz aG93cyBhIHJlZ3Jlc3Npb24gZHVlIHRvIHJlYWwgZGF0YSBiZWluZyBwdXNoZWQgb3V0IG9mIHRo ZSBjYWNoZSBieSBhbGwgdGhvc2UgZXh0cmEgemVyb3MgOykKClsuLi5dCgpPay4gSWYgdGhpcyB3 YXMgcHJvcG9zZWQgYmVmb3JlLCBJJ20gbm90IHN1cmUgaWYgdGhlIGxpbmsgdG8gdGhhdApwYXRj aHNldCBpcyBzdGlsbCBhdmFpbGFibGU/IDopCgpXaGVuIEkgd2FzIHNlYXJjaGluZyAibXlfemVy b19wZm4iIGluIHVwc3RyZWFtIGtlcm5lbCwgREFYIHVzZXMgdGhlCnplcm8gcGFnZXMgdG8gZmls bCB0aGUgaG9sZXMgaW4gb25lIHBhcnRpY3VsYXIgZmlsZSBpbiBkYXhfbG9hZF9ob2xlKCkuCm1t YXAoKSBvbiAvcHJvYy9rY29yZSBjb3VsZCB1c2UgemVybyBwYWdlIGVpdGhlci4KClllcywgaXQn cyBjb3JyZWN0IHRoYXQgdGhlIGRhdGEgY2FjaGUgaGFzIG1vcmUgY2hhbmNlIHRvIGJlIGZsdXNo ZWQgYnkKdGhlc2UgZXh0cmEgemVyb2VzLiBIb3dldmVyLCBpdCdzIG5vdCB3aHkgd2UgY29tcHJv bWlzZSB0aGUgcGVyZm9ybWFuY2UKb24gcmVhZGluZyB6ZXJvIHBhZ2UgYW5kIGRlcHJlc3MgaXQg aW50ZW50aW9uYWxseS4gVGhlIGNhY2hlIGxpbmVzIHdvbid0CmJlIHVzZWQgaWYgdGhlcmUgaXMg bm8gcmVhZGluZyBhY3Rpdml0aWVzIG9uIHplcm8gcGFnZSA6KQoKQ2hlZXJzLApHYXZpbgoKICAK CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1h cm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5v cmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0t a2VybmVsCg== 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.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 28DF1C43465 for ; Mon, 21 Sep 2020 03:01:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CAC342078E for ; Mon, 21 Sep 2020 03:01:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="UNYinvlQ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726328AbgIUC5C (ORCPT ); Sun, 20 Sep 2020 22:57:02 -0400 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:35766 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726104AbgIUC5C (ORCPT ); Sun, 20 Sep 2020 22:57:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1600657020; h=from:from:reply-to: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=YeKw+/y7Dc2RU9VjLNTsXLBHSQ9qLyRYCz78WrOYT30=; b=UNYinvlQjwfskOy4F4KiP4Vd+1Qb8GuElSTNVc6l4W1NDoMdKqiYvsjp3MiAWt4bM+ha06 y/oxwrzlvP37LN6tb3rRfr2/j5GcK+atvQUG3sxkBQ0tPX8VE4z4SQEdp1bU3Lbbz3hh5F +pugu3odp+hInyWP85BqZLV4ENAaFXA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-370-7Gw7oaaNPXi57DyeyO4ITw-1; Sun, 20 Sep 2020 22:56:55 -0400 X-MC-Unique: 7Gw7oaaNPXi57DyeyO4ITw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 47D111005E5B; Mon, 21 Sep 2020 02:56:54 +0000 (UTC) Received: from [10.64.54.34] (vpn2-54-34.bne.redhat.com [10.64.54.34]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C6B495D9D5; Mon, 21 Sep 2020 02:56:51 +0000 (UTC) Reply-To: Gavin Shan Subject: Re: [PATCH 2/2] arm64/mm: Enable color zero pages To: Robin Murphy , Will Deacon Cc: mark.rutland@arm.com, anshuman.khandual@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> From: Gavin Shan Message-ID: <968a5ae7-ebed-8191-15df-6c9860dc72fe@redhat.com> Date: Mon, 21 Sep 2020 12:56:47 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0 MIME-Version: 1.0 In-Reply-To: <33e9a04e-9f93-6a06-273d-284900bc1535@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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