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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5DB3DC433F5 for ; Mon, 18 Oct 2021 13:01:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A94606103B for ; Mon, 18 Oct 2021 13:01:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A94606103B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 1E06C900002; Mon, 18 Oct 2021 09:01:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 18FDB6B0071; Mon, 18 Oct 2021 09:01:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 07F51900002; Mon, 18 Oct 2021 09:01:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0251.hostedemail.com [216.40.44.251]) by kanga.kvack.org (Postfix) with ESMTP id E95976B006C for ; Mon, 18 Oct 2021 09:01:12 -0400 (EDT) Received: from smtpin35.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A0C7A27709 for ; Mon, 18 Oct 2021 13:01:12 +0000 (UTC) X-FDA: 78709568784.35.D50A558 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf26.hostedemail.com (Postfix) with ESMTP id 0FF3820019F4 for ; Mon, 18 Oct 2021 13:01:10 +0000 (UTC) Received: from dggemv711-chm.china.huawei.com (unknown [172.30.72.53]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4HXxhZ6XbWzbnFc; Mon, 18 Oct 2021 20:56:30 +0800 (CST) Received: from dggpemm500002.china.huawei.com (7.185.36.229) by dggemv711-chm.china.huawei.com (10.1.198.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Mon, 18 Oct 2021 21:01:02 +0800 Received: from [10.174.178.178] (10.174.178.178) by dggpemm500002.china.huawei.com (7.185.36.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Mon, 18 Oct 2021 21:01:02 +0800 Message-ID: <6e310e59-c0b6-5ba2-f927-7754c3e9e941@huawei.com> Date: Mon, 18 Oct 2021 21:01:01 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.0.3 Subject: Re: [PATCH v2 1/2] mm/vmalloc: fix numa spreading for large hash tables To: Matthew Wilcox CC: , , , , , , , , References: <20211018123710.1540996-1-chenwandun@huawei.com> <20211018123710.1540996-2-chenwandun@huawei.com> From: Chen Wandun In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed X-Originating-IP: [10.174.178.178] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemm500002.china.huawei.com (7.185.36.229) X-CFilter-Loop: Reflected X-Stat-Signature: 8ejonmmpz8rjk634apet9so83ck5nime Authentication-Results: imf26.hostedemail.com; dkim=none; spf=pass (imf26.hostedemail.com: domain of chenwandun@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=chenwandun@huawei.com; dmarc=pass (policy=none) header.from=huawei.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 0FF3820019F4 X-HE-Tag: 1634562070-250532 Content-Transfer-Encoding: quoted-printable 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: =E5=9C=A8 2021/10/18 20:39, Matthew Wilcox =E5=86=99=E9=81=93: > On Mon, Oct 18, 2021 at 08:37:09PM +0800, Chen Wandun wrote: >> Eric Dumazet reported a strange numa spreading info in [1], and found >> commit 121e6f3258fe ("mm/vmalloc: hugepage vmalloc mappings") introduc= ed >> this issue [2]. >=20 > I think the root problem here is that we have two meanings for > NUMA_NO_NODE. I tend to read it as "The memory can be allocated from > any node", but here it's used to mean "The memory should be spread over > every node". Should we split those out as -1 and -2? Yes, the intent of NUMA_NO_NODE some time is confused. Besides=EF=BC=8CI think NUMA_NO_NODE should consider mempolicy in most cases in the kernel unless it point out explicitly memory can be allocated without considering mempolicy. > . >=20