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 5FC91C4332F for ; Mon, 18 Oct 2021 12:41:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0C16360FC3 for ; Mon, 18 Oct 2021 12:41:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0C16360FC3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 860A86B006C; Mon, 18 Oct 2021 08:41:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 810E76B0071; Mon, 18 Oct 2021 08:41:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6FF4F900002; Mon, 18 Oct 2021 08:41:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0240.hostedemail.com [216.40.44.240]) by kanga.kvack.org (Postfix) with ESMTP id 60EAD6B006C for ; Mon, 18 Oct 2021 08:41:17 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 1557932072 for ; Mon, 18 Oct 2021 12:41:17 +0000 (UTC) X-FDA: 78709518594.05.DE5D8B9 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf13.hostedemail.com (Postfix) with ESMTP id 0C5A4103E0DE for ; Mon, 18 Oct 2021 12:41:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=D0on4HUpG42haSYLV1uyg0Ra8eavO6yawrcHNA7JqNE=; b=l1tP7h9zicMHO1Xl3MTeMZbAT1 gJVT86FtE9nPC2sc0ibmEvIPQEDPSU0V9hJxWPOyjPMkYKziza66AzI69pZyuAYFyQmLn/Gtow2zi HIA/Q4qJWRePWGKRP451c/rVvpMvkiPcNYi4pybAPoyzP2sqERIJjGrejKDzxBEAQMZDAtmpyn9mN dsADP2grJEGxFGHqjYrgM5+M6s8/Fu6PJE2mfG6HmSwBeGjUk++9HM2GdDqymQRBM5lkUkpZna6rC ShpjksJnog80uPOXkahDcSaKZA3SJnFqYbgyEqNZy2fb6/7xA69CBpteX6UROr1fL48yrSkaDenGt GPo4lN8A==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mcRve-00Awmf-Uo; Mon, 18 Oct 2021 12:40:06 +0000 Date: Mon, 18 Oct 2021 13:39:46 +0100 From: Matthew Wilcox To: Chen Wandun Cc: akpm@linux-foundation.org, npiggin@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, edumazet@google.com, wangkefeng.wang@huawei.com, guohanjun@huawei.com, shakeelb@google.com, urezki@gmail.com Subject: Re: [PATCH v2 1/2] mm/vmalloc: fix numa spreading for large hash tables Message-ID: References: <20211018123710.1540996-1-chenwandun@huawei.com> <20211018123710.1540996-2-chenwandun@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211018123710.1540996-2-chenwandun@huawei.com> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 0C5A4103E0DE X-Stat-Signature: yjhxra69sp53gdzni43j7h8fuq8fk9py Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=l1tP7h9z; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-HE-Tag: 1634560873-459630 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, 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") introduced > this issue [2]. 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?