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=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_2 autolearn=no 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 8F797C433E0 for ; Mon, 6 Jul 2020 13:05:58 +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 57A5F2070C for ; Mon, 6 Jul 2020 13:05:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="kyxqZ5QH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 57A5F2070C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=Huawei.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:MIME-Version:References:In-Reply-To:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=weSwyBlijHiS+c+ycBdFFh5vscOn+eYK0yRU98iqbHw=; b=kyxqZ5QHSCVnvCUPlJxa1/W6g oWtXZUQPNzI51lDuHa4V7/o0pkbRcOdE6S220ige5fMk/klcBRkU2IRscO4IR9Gq2cAzabWKpsIsL tTfgjhKZnHb5RL2u0i5G6iYOkwVRMOev9lDdFi82/llPu5xwMqQ+Vb1OtfShCqSEWKpvp2HOi3Cz/ Y8OsCOGvk2ngCoClIZW1TtoM2oKnAvsAo2fTMfR+4VqeOSghzJL63wj/g2Y1zvZRttlksf2aZSuTq imvhY9qXV2TNT7S1Eg4rn/jaDNq7nvG3BsoKKYFg1yY6cAdF3NcaSvwEpUcQB0JacAhhZsipvs1ps 0Y1Wcs2lg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jsQnN-0003Wn-Rj; Mon, 06 Jul 2020 13:04:29 +0000 Received: from lhrrgout.huawei.com ([185.176.76.210] helo=huawei.com) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jsQnJ-0003VY-AI for linux-arm-kernel@lists.infradead.org; Mon, 06 Jul 2020 13:04:27 +0000 Received: from lhreml710-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D5D78A10EBC0DE971CF6; Mon, 6 Jul 2020 14:04:21 +0100 (IST) Received: from localhost (10.52.123.111) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 6 Jul 2020 14:04:21 +0100 Date: Mon, 6 Jul 2020 14:03:17 +0100 From: Jonathan Cameron To: Justin He Subject: Re: [PATCH 1/3] arm64/numa: set numa_off to false when numa node is fake Message-ID: <20200706140317.00002f53@Huawei.com> In-Reply-To: References: <20200706011947.184166-1-justin.he@arm.com> <20200706011947.184166-2-justin.he@arm.com> <20200706112921.00006f7f@Huawei.com> <20200706114605.000050ac@Huawei.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; i686-w64-mingw32) MIME-Version: 1.0 X-Originating-IP: [10.52.123.111] X-ClientProxiedBy: lhreml717-chm.china.huawei.com (10.201.108.68) To lhreml710-chm.china.huawei.com (10.201.108.61) X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200706_090425_526982_58AEC7D1 X-CRM114-Status: GOOD ( 33.31 ) 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: Baoquan He , Kaly Xin , Catalin Marinas , David Hildenbrand , Chuhong Yuan , "linux-kernel@vger.kernel.org" , Mike Rapoport , "linux-mm@kvack.org" , Andrew Morton , Will Deacon , "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 T24gTW9uLCA2IEp1bCAyMDIwIDEyOjQ3OjUxICswMDAwCkp1c3RpbiBIZSA8SnVzdGluLkhlQGFy bS5jb20+IHdyb3RlOgoKPiBIaSBKb25hdGhhbiwgdGhhbmtzIGZvciB0aGUgY29tbWVudHMuCj4g Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+ID4gRnJvbTogSm9uYXRoYW4gQ2FtZXJv biA8Sm9uYXRoYW4uQ2FtZXJvbkBIdWF3ZWkuY29tPgo+ID4gU2VudDogTW9uZGF5LCBKdWx5IDYs IDIwMjAgNjo0NiBQTQo+ID4gVG86IEp1c3RpbiBIZSA8SnVzdGluLkhlQGFybS5jb20+Cj4gPiBD YzogQ2F0YWxpbiBNYXJpbmFzIDxDYXRhbGluLk1hcmluYXNAYXJtLmNvbT47IFdpbGwgRGVhY29u Cj4gPiA8d2lsbEBrZXJuZWwub3JnPjsgQW5kcmV3IE1vcnRvbiA8YWtwbUBsaW51eC1mb3VuZGF0 aW9uLm9yZz47IE1pa2UKPiA+IFJhcG9wb3J0IDxycHB0QGxpbnV4LmlibS5jb20+OyBCYW9xdWFu IEhlIDxiaGVAcmVkaGF0LmNvbT47IENodWhvbmcgWXVhbgo+ID4gPGhzbGVzdGVyOTZAZ21haWwu Y29tPjsgbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOyBsaW51eC0KPiA+IGtl cm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LW1tQGt2YWNrLm9yZzsgS2FseSBYaW4gPEthbHku WGluQGFybS5jb20+Cj4gPiBTdWJqZWN0OiBSZTogW1BBVENIIDEvM10gYXJtNjQvbnVtYTogc2V0 IG51bWFfb2ZmIHRvIGZhbHNlIHdoZW4gbnVtYSBub2RlCj4gPiBpcyBmYWtlCj4gPiAKPiA+IE9u IE1vbiwgNiBKdWwgMjAyMCAxMToyOToyMSArMDEwMAo+ID4gSm9uYXRoYW4gQ2FtZXJvbiA8Sm9u YXRoYW4uQ2FtZXJvbkBIdWF3ZWkuY29tPiB3cm90ZToKPiA+ICAgCj4gPiA+IE9uIE1vbiwgNiBK dWwgMjAyMCAwOToxOTo0NSArMDgwMAo+ID4gPiBKaWEgSGUgPGp1c3Rpbi5oZUBhcm0uY29tPiB3 cm90ZToKPiA+ID4KPiA+ID4gSGksCj4gPiA+ICAKPiA+ID4gPiBQcmV2aW91c2x5LCBudW1hX29m ZiBpcyBzZXQgdG8gdHJ1ZSB1bmNvbmRpdGlvbmFsbHkgaW4gIAo+ID4gZHVtbXlfbnVtYV9pbml0 KCksICAKPiA+ID4gPiBldmVuIGlmIHRoZXJlIGlzIGEgZmFrZSBudW1hIG5vZGUuCj4gPiA+ID4K PiA+ID4gPiBCdXQgYWNwaSB3aWxsIHRyYW5zbGF0ZSBub2RlIGlkIHRvIE5VTUFfTk9fTk9ERSgt MSkgaW4gIAo+ID4gYWNwaV9tYXBfcHhtX3RvX25vZGUoKSAgCj4gPiA+ID4gYmVjYXVzZSBpdCBy ZWdhcmRzIG51bWFfb2ZmIGFzIHR1cm5pbmcgb2ZmIHRoZSBudW1hIG5vZGUuICAKPiA+ID4KPiA+ ID4gVGhhdCBpcyBjb3JyZWN0LiAgSXQgaXMgb3BlcmF0aW5nIGV4YWN0bHkgYXMgaXQgc2hvdWxk LCBpZiBTUkFUIGhhc24ndCAgCj4gPiBiZWVuIHBhcnNlZCAgCj4gPiA+IGFuZCB5b3UgYXJlIG9u IEFDUEkgcGxhdGZvcm0gdGhlcmUgYXJlIG5vIG5vZGVzLiAgVGhleSBjYW5ub3QgYmUgY3JlYXRl ZCAgCj4gPiBhdCAgCj4gPiA+IHNvbWUgbGF0ZXIgZGF0ZS4gIFRoZSBkdW1teSBjb2RlIGRvZXNu J3QgY2hhbmdlIHRoaXMuIEl0IGp1c3QgZG9lcyAgCj4gPiBlbm91Z2ggdG8gY2FycnkgIAo+ID4g PiBvbiBvcGVyYXRpbmcgd2l0aCBubyBzcGVjaWZpZWQgbm9kZXMuCj4gPiA+ICAKPiA+ID4gPgo+ ID4gPiA+IFdpdGhvdXQgdGhpcyBwYXRjaCwgcG1lbSBjYW4ndCBiZSBwcm9iZWQgYXMgYSBSQU0g ZGV2aWNlIG9uIGFybTY0IGlmICAKPiA+IFNSQVQgdGFibGUgIAo+ID4gPiA+IGlzbid0IHByZXNl bnQuCj4gPiA+ID4KPiA+ID4gPiAkbmRjdGwgY3JlYXRlLW5hbWVzcGFjZSAtZmUgbmFtZXNwYWNl MC4wIC0tbW9kZT1kZXZkYXggLS1tYXA9ZGV2IC1zIDFnICAKPiA+IC1hIDY0SyAgCj4gPiA+ID4g a21lbSBkYXgwLjA6IHJlamVjdGluZyBEQVggcmVnaW9uIFttZW0gMHgyNDA0MDAwMDAtMHgyYmZm ZmZmZmZdIHdpdGggIAo+ID4gaW52YWxpZCBub2RlOiAtMSAgCj4gPiA+ID4ga21lbTogcHJvYmUg b2YgZGF4MC4wIGZhaWxlZCB3aXRoIGVycm9yIC0yMgo+ID4gPiA+Cj4gPiA+ID4gVGhpcyBmaXhl cyBpdCBieSBzZXR0aW5nIG51bWFfb2ZmIHRvIGZhbHNlLiAgCj4gPiA+Cj4gPiA+IFdpdGhvdXQg dGhlIFNSQVQgcHJvdGVjdGlvbiBwYXRjaCBbMV0geW91IG1heSB3ZWxsIHJ1biBpbnRvIHByb2Js ZW1zICAKPiAKPiBTb3JyeSwgZG9lc24ndCBxdWl0ZSB1bmRlcnN0YW5kIGhlcmUuIERvIHlvdSBt ZWFuIHlvdXIgWzFdIGNhbiByZXNvbHZlIHRoaXMKPiBpc3N1ZT8gQnV0IGFjcGlfbWFwX3B4bV90 b19ub2RlKCkgaGFzIHJldHVybmVkIHdpdGggTlVNQV9OT19OT0RFIGFmdGVyCj4gZm9sbG93aW5n IGNoZWNrOgo+IAlpZiAocHhtIDwgMCB8fCBweG0gPj0gTUFYX1BYTV9ET01BSU5TIHx8IG51bWFf b2ZmKQo+IAkJcmV0dXJuIE5VTUFfTk9fTk9ERTsKClRoZSBwb2ludCBvZiB0aGF0IHBhdGNoIGlz IGl0IHdpbGwgbWFrZSBpdCBzYWZlIHRvIHJlbW92ZSB0aGUgbnVtYV9vZmYgYmVjYXVzZQphbnkg bGF0ZXIgYWNjaWRlbnRhbCByZWZlcmVuY2UgdG8gYSBub24gZXhpc3RlbnQgbm9kZSAoaS5lLiBv bmUgbm90IGRlZmluZWQKaW4gU1JBVCkgd2lsbCBub3QgYmxvdyB1cC4KCkl0IGRvZXNuJ3QgZml4 IHlvdXIgb3JpZ2luYWwgcHJvYmxlbS4gV2hhdCBpdCBkb2VzIGRvLCBpcyBmaXggdGhlIG5ldyBw cm9ibGVtIGNhc2UKeW91IGludHJvZHVjZSBieSByZW1vdmluZyBudW1hX29mZiBiZWxvdy4gIEl0 IGVuc3VyZXMgeW91IHN0aWxsIHJldHVybiBOVU1BX05PX05PREUKaW4gY2FzZXMgd2hpY2ggc2hv dWxkIGRvIHNvIChpLmUuIGFsbCBvZiB0aGVtIGlmIHlvdSBoYXZlIG5vIFNSQVQgYW5kIGFyZSB1 c2luZyBBQ1BJKS4KCk9mIGNvdXJzZSwgeW91IGNvdWxkIGp1c3Qgbm90IHJlbW92ZSB0aGUgbnVt YV9vZmYgPSB0cnVlIGJpdCB0aGVuIHlvdSB3b24ndCBoaXQKdGhhdCBjb25kaXRpb24gYW55d2F5 LiBUaGVyZSBhcmUgcGxlbnR5IG9mIG90aGVyIHJlYXNvbnMgZm9yIHRoZSBTUkFUIHBhdGNoIHRo b3VnaCwKaXQganVzdCBoYXBwZW5zIHRvIGNsb3NlIGEgcHJvYmxlbSB5b3Ugd2VyZSBpbnRyb2R1 Y2luZyBoZXJlIGFzIHdlbGwuCgpGb3IgcmVmZXJlbmNlIHdlIGhhZCBhbiBBTUQgcGxhdGZvcm0g dGhhdCBoYWQgbm8gU1JBVCwgYnV0IHByb3ZpZGVkIF9QWE0gZm9yCmEgZmV3IG5vZGVzIGluIGl0 cyBEU0RULiAgIFRoYXQgcmVzdWx0IGluIG5vbiBib290aW5nIHN5c3RlbXMuICBJdCBvbmx5IGFm ZmVjdGVkCng4NiBiZWNhdXNlIEFSTTY0IGhhZCB0aGF0IG51bWFfb2ZmID0gdHJ1ZSBiZWluZyBz ZXQuICBJZiB3ZSBjaGFuZ2UgdGhlIGFybTY0IGNhc2UKd2l0aG91dCB0aGUgcGF0Y2ggdG8gZW5z dXJlIHRoZSB1bmRlcmx5aW5nIHByb2JsZW0gaXMgZml4ZWQsIHlvdSBhcmUgdmVyeSBsaWtlbHkg dG8gaGl0CnRoZSBlcXVpdmFsZW50IHByb2JsZW0uIFRoZXJlIG1heSB3ZWxsIGJlIHBsYXRmb3Jt cyBvdXQgdGhlcmUgcmVseWluZyBvbiB0aGF0IHF1aXJrCm9mIHdoYXQgdGhlIGNvZGUgY3VycmVu dGx5IGRvZXMuCgo+IFNlZW1zIGV2ZW4gd2l0aCB5b3VyIFsxXSBwYXRjaCwgaXQgaXMgbm90IGhl bHBmdWw/IFRoYW5rcyBmb3IgY2xhcmlmaWNhdGlvbgo+IGlmIG15IHVuZGVyc3RhbmRpbmcgaXMg d3JvbmcuCj4gWzFdIGh0dHBzOi8vcGF0Y2h3b3JrLmtlcm5lbC5vcmcvcGF0Y2gvMTE2MzIwNjMv Cj4gCj4gPiA+IGJlY2F1c2Ugc29tZW9uZSBzb21ld2hlcmUgd2lsbCBoYXZlIF9QWE0gaW4gYSBE U0RUIGJ1dCB3aWxsCj4gPiA+IGhhdmUgYSBub24gZXhpc3RlbnQgU1JBVC4gICBXZSBoYWQgdGhp cyBoYXBwZW4gb24gYW4gQU1EIHBsYXRmb3JtIHdoZW4gIAo+ID4gd2UgIAo+ID4gPiB0cmllZCB0 byBpbnRyb2R1Y2Ugd29ya2luZyBfUFhNIHN1cHBvcnQgZm9yIFBDSS4gWzJdCj4gPiA+Cj4gPiA+ IFNvIHdoaWxzdCB0aGlzIHNlZW1zIHN1cGVyZmljaWFsbHkgc2FmZSwgSSdkIGRlZmluaXRlbHkg YmUgY3Jvc3NpbmcgeW91ciAgCj4gPiBmaW5nZXJzLiAgCj4gPiA+IE5vdGUsIGF0IHRoYXQgdGlt ZSBJIHByb3Bvc2VkIHB1dHRpbmcgdGhlIG51bWFfb2ZmID0gZmFsc2UgaW50byB0aGUgeDg2ICAK PiA+IGNvZGUgIAo+ID4gPiBwYXRoIHByZWNpc2VseSB0byBjdXQgb3V0IHRoYXQgcG9zc2liaWxp dHkgKHdhcyByZWplY3RlZCBhdCB0aGUgdGltZSwgYXQgIAo+ID4gbGVhc3QgIAo+ID4gPiBwYXJ0 bHkgYmVjYXVzZSB0aGUgY2xhcmlmaWNhdGlvbnMgdG8gdGhlIEFDUEkgc3BlYyB3ZXJlIG5vdCBw dWJpbGMuKQo+ID4gPgo+ID4gPiBUaGUgcGF0Y2ggaW4gWzFdIHNob3VsZCBzb3J0IHRoaW5ncyBv dXQgaG93ZXZlciBieSBlbnN1cmluZyB3ZSBvbmx5ICAKPiA+IGNyZWF0ZSAgCj4gPiA+IG5ldyBk b21haW5zIHdoZXJlIHdlIHNob3VsZCBhY3R1YWxseSBiZSBkb2luZyBzby4gSG93ZXZlciwgaW4g eW91ciBjYXNlCj4gPiA+IGl0IHdpbGwgcmV0dXJuIE5VTUFfTk9fTk9ERSBhbnl3YXkgc28gdGhp cyBpc24ndCB0aGUgcmlnaHQgd2F5IHRvIGZpeCAgCj4gPiB0aGluZ3MuICAKPiAKPiBPa2F5LCBs ZXQgbWUgdHJ5IHRvIHN1bW1hcml6ZSwgdGhlcmUgbWlnaHQgYmUgMyBwb3NzaWJsZSBmaXhpbmcg d2F5czoKPiAxLiB0aGlzIHBhdGNoLCBzZWVtcyBpdCBpcyBub3Qgc2F0aXNmaWVkIGJ5IHlvdSBh bmQgRGF2aWQg8J+YiQo+IDIuIG15IHByZXZpb3VzIHByb3Bvc2FsIFsyXSwgc2ltaWxhciBhcyB3 aGF0IERhdmlkIHN1Z2dlc3RlZAoKVGhhdCBsb29rcyBsaWtlIHRoZSBjb3JyZWN0IGFwcHJvYWNo IHRvIG1lIGFzIHdlbGwuCgo+IDMuIHJlbW92ZSBudW1hX29mZiBjaGVjayBpbiBhY3BpX21hcF9w eG1fdG9fbm9kZSgpCgpObyB3YXkgdG8gdGhhdCBvbmUuICBUaGUgb25seSByaWdodCByZXR1cm4g dmFsdWUgZnJvbSBhY3BpX21hcF9weG1fdG9fbm9kZQp3aGVuIG5vIG5vZGUgaXMgcHJvdmlkZWQg KGFsd2F5cyB0aGUgY2FzZSBpZiB5b3UgaGF2ZSBubyBTUkFUKSBpcwpOVU1BX05PX05PREUuICBE byBub3QgcGFwZXIgb3ZlciB0aGF0IC0gZml4IHRoZSBjYWxsZXIgdG8gaGFuZGxlCmEgcGVyZmVj dGx5IHZhbGlkIHJldHVybiB2YWx1ZS4KCkpvbmF0aGFuCgo+IGUuZy4KPiAuLi4KPiAJaWYgKHB4 bSA8IDAgfHwgcHhtID49IE1BWF9QWE1fRE9NQUlOUyAvKnx8IG51bWFfb2ZmKi8pCj4gCQlyZXR1 cm4gTlVNQV9OT19OT0RFOwo+IAo+IFsyXSBodHRwczovL2xrbWwub3JnL2xrbWwvMjAxOS84LzE2 LzM2Nwo+IAo+IAo+IC0tCj4gQ2hlZXJzLAo+IEp1c3RpbiAoSmlhIEhlKQo+IAo+IAoKCgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2Vy bmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0 cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVs Cg== 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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 autolearn=no 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 7E659C433E0 for ; Mon, 6 Jul 2020 13:04:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 46F992070C for ; Mon, 6 Jul 2020 13:04:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 46F992070C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=Huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8A01D6B0002; Mon, 6 Jul 2020 09:04:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 851066B0005; Mon, 6 Jul 2020 09:04:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 740906B0006; Mon, 6 Jul 2020 09:04:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0096.hostedemail.com [216.40.44.96]) by kanga.kvack.org (Postfix) with ESMTP id 60DB46B0002 for ; Mon, 6 Jul 2020 09:04:55 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 25438180ACEFC for ; Mon, 6 Jul 2020 13:04:55 +0000 (UTC) X-FDA: 77007670950.08.form33_4a124bb26eac Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id 167B31819C3B0 for ; Mon, 6 Jul 2020 13:04:25 +0000 (UTC) X-HE-Tag: form33_4a124bb26eac X-Filterd-Recvd-Size: 7676 Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Mon, 6 Jul 2020 13:04:24 +0000 (UTC) Received: from lhreml710-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D5D78A10EBC0DE971CF6; Mon, 6 Jul 2020 14:04:21 +0100 (IST) Received: from localhost (10.52.123.111) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 6 Jul 2020 14:04:21 +0100 Date: Mon, 6 Jul 2020 14:03:17 +0100 From: Jonathan Cameron To: Justin He CC: Catalin Marinas , Will Deacon , Andrew Morton , Mike Rapoport , Baoquan He , Chuhong Yuan , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Kaly Xin , David Hildenbrand Subject: Re: [PATCH 1/3] arm64/numa: set numa_off to false when numa node is fake Message-ID: <20200706140317.00002f53@Huawei.com> In-Reply-To: References: <20200706011947.184166-1-justin.he@arm.com> <20200706011947.184166-2-justin.he@arm.com> <20200706112921.00006f7f@Huawei.com> <20200706114605.000050ac@Huawei.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.52.123.111] X-ClientProxiedBy: lhreml717-chm.china.huawei.com (10.201.108.68) To lhreml710-chm.china.huawei.com (10.201.108.61) X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 167B31819C3B0 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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: On Mon, 6 Jul 2020 12:47:51 +0000 Justin He wrote: > Hi Jonathan, thanks for the comments. >=20 > > -----Original Message----- > > From: Jonathan Cameron > > Sent: Monday, July 6, 2020 6:46 PM > > To: Justin He > > Cc: Catalin Marinas ; Will Deacon > > ; Andrew Morton ; Mike > > Rapoport ; Baoquan He ; Chuhong Yuan > > ; linux-arm-kernel@lists.infradead.org; linux- > > kernel@vger.kernel.org; linux-mm@kvack.org; Kaly Xin > > Subject: Re: [PATCH 1/3] arm64/numa: set numa_off to false when numa no= de > > is fake > >=20 > > On Mon, 6 Jul 2020 11:29:21 +0100 > > Jonathan Cameron wrote: > > =20 > > > On Mon, 6 Jul 2020 09:19:45 +0800 > > > Jia He wrote: > > > > > > Hi, > > > =20 > > > > Previously, numa_off is set to true unconditionally in =20 > > dummy_numa_init(), =20 > > > > even if there is a fake numa node. > > > > > > > > But acpi will translate node id to NUMA_NO_NODE(-1) in =20 > > acpi_map_pxm_to_node() =20 > > > > because it regards numa_off as turning off the numa node. =20 > > > > > > That is correct. It is operating exactly as it should, if SRAT hasn'= t =20 > > been parsed =20 > > > and you are on ACPI platform there are no nodes. They cannot be crea= ted =20 > > at =20 > > > some later date. The dummy code doesn't change this. It just does =20 > > enough to carry =20 > > > on operating with no specified nodes. > > > =20 > > > > > > > > Without this patch, pmem can't be probed as a RAM device on arm64 i= f =20 > > SRAT table =20 > > > > isn't present. > > > > > > > > $ndctl create-namespace -fe namespace0.0 --mode=3Ddevdax --map=3Dde= v -s 1g =20 > > -a 64K =20 > > > > kmem dax0.0: rejecting DAX region [mem 0x240400000-0x2bfffffff] wit= h =20 > > invalid node: -1 =20 > > > > kmem: probe of dax0.0 failed with error -22 > > > > > > > > This fixes it by setting numa_off to false. =20 > > > > > > Without the SRAT protection patch [1] you may well run into problems = =20 >=20 > Sorry, doesn't quite understand here. Do you mean your [1] can resolve th= is > issue? But acpi_map_pxm_to_node() has returned with NUMA_NO_NODE after > following check: > if (pxm < 0 || pxm >=3D MAX_PXM_DOMAINS || numa_off) > return NUMA_NO_NODE; The point of that patch is it will make it safe to remove the numa_off beca= use any later accidental reference to a non existent node (i.e. one not defined in SRAT) will not blow up. It doesn't fix your original problem. What it does do, is fix the new probl= em case you introduce by removing numa_off below. It ensures you still return NUMA= _NO_NODE in cases which should do so (i.e. all of them if you have no SRAT and are u= sing ACPI). Of course, you could just not remove the numa_off =3D true bit then you won= 't hit that condition anyway. There are plenty of other reasons for the SRAT patch= though, it just happens to close a problem you were introducing here as well. For reference we had an AMD platform that had no SRAT, but provided _PXM for a few nodes in its DSDT. That result in non booting systems. It only aff= ected x86 because ARM64 had that numa_off =3D true being set. If we change the a= rm64 case without the patch to ensure the underlying problem is fixed, you are very l= ikely to hit the equivalent problem. There may well be platforms out there relying on th= at quirk of what the code currently does. > Seems even with your [1] patch, it is not helpful? Thanks for clarificati= on > if my understanding is wrong. > [1] https://patchwork.kernel.org/patch/11632063/ >=20 > > > because someone somewhere will have _PXM in a DSDT but will > > > have a non existent SRAT. We had this happen on an AMD platform whe= n =20 > > we =20 > > > tried to introduce working _PXM support for PCI. [2] > > > > > > So whilst this seems superficially safe, I'd definitely be crossing y= our =20 > > fingers. =20 > > > Note, at that time I proposed putting the numa_off =3D false into the= x86 =20 > > code =20 > > > path precisely to cut out that possibility (was rejected at the time,= at =20 > > least =20 > > > partly because the clarifications to the ACPI spec were not pubilc.) > > > > > > The patch in [1] should sort things out however by ensuring we only = =20 > > create =20 > > > new domains where we should actually be doing so. However, in your ca= se > > > it will return NUMA_NO_NODE anyway so this isn't the right way to fix= =20 > > things. =20 >=20 > Okay, let me try to summarize, there might be 3 possible fixing ways: > 1. this patch, seems it is not satisfied by you and David =F0=9F=98=89 > 2. my previous proposal [2], similar as what David suggested That looks like the correct approach to me as well. > 3. remove numa_off check in acpi_map_pxm_to_node() No way to that one. The only right return value from acpi_map_pxm_to_node when no node is provided (always the case if you have no SRAT) is NUMA_NO_NODE. Do not paper over that - fix the caller to handle a perfectly valid return value. Jonathan > e.g. > ... > if (pxm < 0 || pxm >=3D MAX_PXM_DOMAINS /*|| numa_off*/) > return NUMA_NO_NODE; >=20 > [2] https://lkml.org/lkml/2019/8/16/367 >=20 >=20 > -- > Cheers, > Justin (Jia He) >=20 >=20