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=-9.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_GIT 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 5037CC433E1 for ; Fri, 19 Jun 2020 16:25:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 16D8C217A0 for ; Fri, 19 Jun 2020 16:25:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 16D8C217A0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A24478D00E5; Fri, 19 Jun 2020 12:24:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7BAD68D00E6; Fri, 19 Jun 2020 12:24:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 65CB78D00E9; Fri, 19 Jun 2020 12:24:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0224.hostedemail.com [216.40.44.224]) by kanga.kvack.org (Postfix) with ESMTP id 457168D00E5 for ; Fri, 19 Jun 2020 12:24:47 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 0ED57180AD80F for ; Fri, 19 Jun 2020 16:24:47 +0000 (UTC) X-FDA: 76946485014.13.drum52_2806e4926e1a Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id 9E9A2181411F9 for ; Fri, 19 Jun 2020 16:24:31 +0000 (UTC) X-HE-Tag: drum52_2806e4926e1a X-Filterd-Recvd-Size: 4084 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf10.hostedemail.com (Postfix) with ESMTP for ; Fri, 19 Jun 2020 16:24:30 +0000 (UTC) IronPort-SDR: aZHWzDKVlfUY/OCSU1Y/Nj3mqaPZemqKMMh/Noa1yL/PGDHzu69EIvNV1QB3PN26gH3YAqqJtj H3GNGNYNOKLw== X-IronPort-AV: E=McAfee;i="6000,8403,9657"; a="141280136" X-IronPort-AV: E=Sophos;i="5.75,255,1589266800"; d="scan'208";a="141280136" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jun 2020 09:24:28 -0700 IronPort-SDR: oLF0Yn6mSVHJnqoQqHhr0/SypkAj2C8XbjglXisgJgl5oo7fTmKSy5d9E4GfOfu9Ortv8mESf0 hfsG5EujIMvQ== X-IronPort-AV: E=Sophos;i="5.75,255,1589266800"; d="scan'208";a="264367949" Received: from sjiang-mobl2.ccr.corp.intel.com (HELO bwidawsk-mobl5.local) ([10.252.131.131]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jun 2020 09:24:28 -0700 From: Ben Widawsky To: linux-mm Cc: Ben Widawsky , Andrew Morton , Lee Schermerhorn Subject: [PATCH 02/18] mm/mempolicy: Use node_mem_id() instead of node_id() Date: Fri, 19 Jun 2020 09:24:09 -0700 Message-Id: <20200619162425.1052382-3-ben.widawsky@intel.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20200619162425.1052382-1-ben.widawsky@intel.com> References: <20200619162425.1052382-1-ben.widawsky@intel.com> MIME-Version: 1.0 X-Rspamd-Queue-Id: 9E9A2181411F9 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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: Calling out some distinctions first as I understand it, and the reasoning of the patch: numa_node_id() - The node id for the currently running CPU. numa_mem_id() - The node id for the closest memory node. The case where they are not the same is CONFIG_HAVE_MEMORYLESS_NODES. Only ia64 and powerpc support this option, so it is perhaps not a very interesting situation to most. The question is, when you do want which? numa_node_id() is definitely what's desired if MPOL_PREFERRED, or MPOL_LOCAL were used, since the ABI states "This mode specifies "local allocation"; the memory is allocated on the node of the CPU that triggered the allocation (the "local node")." It would be weird, though not impossible to set this policy on a CPU that has memoryless nodes. A more likely way to hit this is with interleaving. The current interfaces will return some equally weird thing, but at least it's symmetric. Therefore, in cases where the node is being queried for the currently running process, it probably makes sense to use numa_node_id(). For other cases however, when CPU is trying to obtain the "local" memory, numa_mem_id() already contains this and should be used instead. This really should only effect configurations where CONFIG_HAVE_MEMORYLESS_NODES=3Dy, and even on those machines it's quite possible the ultimate behavior would be identical. Cc: Andrew Morton Cc: Lee Schermerhorn Signed-off-by: Ben Widawsky --- mm/mempolicy.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/mempolicy.c b/mm/mempolicy.c index 36ee3267c25f..99e0f3f9c4a6 100644 --- a/mm/mempolicy.c +++ b/mm/mempolicy.c @@ -1991,7 +1991,7 @@ static unsigned offset_il_node(struct mempolicy *po= l, unsigned long n) int nid; =20 if (!nnodes) - return numa_node_id(); + return numa_mem_id(); target =3D (unsigned int)n % nnodes; nid =3D first_node(pol->v.nodes); for (i =3D 0; i < target; i++) @@ -2049,7 +2049,7 @@ int huge_node(struct vm_area_struct *vma, unsigned = long addr, gfp_t gfp_flags, nid =3D interleave_nid(*mpol, vma, addr, huge_page_shift(hstate_vma(vma))); } else { - nid =3D policy_node(gfp_flags, *mpol, numa_node_id()); + nid =3D policy_node(gfp_flags, *mpol, numa_mem_id()); if ((*mpol)->mode =3D=3D MPOL_BIND) *nodemask =3D &(*mpol)->v.nodes; } --=20 2.27.0