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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 42BD1C48BC3 for ; Tue, 20 Feb 2024 06:27:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D14166B007D; Tue, 20 Feb 2024 01:27:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CC4CB6B007E; Tue, 20 Feb 2024 01:27:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B8CC86B0081; Tue, 20 Feb 2024 01:27:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A7ED46B007D for ; Tue, 20 Feb 2024 01:27:08 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 6EEB11A0325 for ; Tue, 20 Feb 2024 06:27:08 +0000 (UTC) X-FDA: 81811199736.27.A77D2F5 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.21]) by imf16.hostedemail.com (Postfix) with ESMTP id A4E1E18000D for ; Tue, 20 Feb 2024 06:27:05 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=iLavUBgs; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf16.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.21 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708410426; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/fORlfG/7fZ3d6+JBtFGDwuKFFIjJHHi7ulGr6I7Z4I=; b=D2dN1aVhjeCixAH0VhCjB+SwpUTOLCmy4qDW49FX3UgcJgNZsQsPeFSJbRKndzWZU8zmiA SDY9J/kh5I/32jlzeQBn+L3226V6AXWoI/q+H+h50skKjQiMwGVJ/FoEdPmj4WC14tSk2g jv7iYmsdGePhiaOv2/YNScCbx4eav9w= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=iLavUBgs; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf16.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.21 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708410426; a=rsa-sha256; cv=none; b=s8ZePGTANpnlpErOhHgqsE2hxSQqRakHyAMIALLjuh+1oCp31SFIYi5sTclqRNGNfvwmZL Z9LmuJ5YH56bBuVTPvWq30uuEvq/E4MnnaM4xXP/pxDN4wBaJeso08jOcMjgNMLRJ+C/6L dNif8CT1i4NMWhmJYUkPR1PqOBS1JlE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708410426; x=1739946426; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=KjbpEsZcL6BLoOczV14V5gdnm8XEq0JhlG2bKfRK0nA=; b=iLavUBgscIjNWgVM7ZFgufHH+usuLS80Mxj8bTjck0c07ILDi7Pt2ENZ J8goQGkj1N8rrluTuwOZ2tcRfLaZS/nQpa0LnPxlI85uGe0SpxphTfvOg a4i6Asn6tFO8NEYvfEp77p/udZUTlhBN+tH194djdnTDyARITiIwF4l5a bXvS4mKhmudjRJ36QP/ZvbAH8dMEmjoI778mVIho6AKs2CDwFCDrNfZKS Fg28TpHFo6Wsl7Yd7j3FNfZDAMY94ioOsbLEdR2UsURgLfLAZ2/T/QkNP ZZi4M6C2fb6ByWCTTab1xxExL42XAplO86TB4+YP18D9dFvCI3K120Sw+ w==; X-IronPort-AV: E=McAfee;i="6600,9927,10989"; a="2401589" X-IronPort-AV: E=Sophos;i="6.06,172,1705392000"; d="scan'208";a="2401589" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by orvoesa113.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Feb 2024 22:27:04 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,172,1705392000"; d="scan'208";a="27842144" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Feb 2024 22:26:59 -0800 From: "Huang, Ying" To: "Aneesh Kumar K.V" Cc: Andrew Morton , Donet Tom , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dave Hansen , Mel Gorman , Ben Widawsky , Feng Tang , Michal Hocko , Andrea Arcangeli , Peter Zijlstra , Ingo Molnar , Rik van Riel , Johannes Weiner , Matthew Wilcox , Mike Kravetz , Vlastimil Babka , Dan Williams , Hugh Dickins , Kefeng Wang , Suren Baghdasaryan Subject: Re: [PATCH 1/3] mm/mempolicy: Use the already fetched local variable In-Reply-To: <21f343fa-84a7-4539-91e2-6fc963dbfb62@kernel.org> (Aneesh Kumar K. V.'s message of "Tue, 20 Feb 2024 09:40:00 +0530") References: <9c3f7b743477560d1c5b12b8c111a584a2cc92ee.1708097962.git.donettom@linux.ibm.com> <20240218133851.22c22b55460e866a099be5ce@linux-foundation.org> <63a0f7c4-3c3f-4097-9a24-d1e3fc7b6030@linux.ibm.com> <20240219172130.82a16c1ebecbf8ba86a8987d@linux-foundation.org> <21f343fa-84a7-4539-91e2-6fc963dbfb62@kernel.org> Date: Tue, 20 Feb 2024 14:25:03 +0800 Message-ID: <87frxnps8w.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Queue-Id: A4E1E18000D X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: xujjfajdzne4uxg6enj1ahezizfa93ur X-HE-Tag: 1708410425-255604 X-HE-Meta: U2FsdGVkX18sCidzV1psEcaQpHoyOq0gTYLvpEm38qAx6E96HYHAPfyYqkl4Ud84lJRgILl6dtn3fPG4oZt1XRSlQV6phKClo1usSZuUGVbTozjjLQ4WxFWaH5r3RK/LpO1U/7bkcbSnLpVvo25E6Tnud+ZAlXg7YUwtkyolSNeRduMuLKfyt6wsq4Pka5jhsdPX+jgmRMQhWEa+VmH/QIcHmqS4z9pEb8DWiYNA/50nnWCf8hJdq2THdzaChfab2t8Mnc0R/ukTrK/J1khUijPrHbkmxD5FQQHisebVwf7tTJsIBv1EjRDOxLDVjHN4PU0WheByHkHkW4qGbnLyLG3RmgbI81nioEj2NsWHBw2tOAE8N7d9AdhwXTG1ncl7pRHLiCmPMRnTuOLOHhABQuJcLjMDhl9rtsLurF5ZLNWPM/la8sLLpHmnJITcjoLv1bIWH1N+UHfT2kR7W9cSqhwDBQG8xDdSfQl50ggEp+BZ2OhapPYkYRA6rkKq9LLebZAh1xxawmuV1av6+Lr8u+zZv3KsFLYB4Okm85OlmU1qCFrgzrDOpWkaJWXoD9F3L+uIvzwWn6TZKtTmKmZKJ0kywgRS8ckEgZCYtKXgrt2l97+EsXi2USAGwo0MoOjsyDA4cDm2Y/ZAc8nql5b6bYomAkuiJ0WY51YjJXEeDkbxmwjs4AKO5nsAKvJqC6JKvWsshamBCX5nJ/ns10p0ifYNtuDuVciqARuog7Q+sk6KukPAnnUPzUxL4wXFa8KQYiIPhpRFtBxZkCCzGfVKgfpJ84chC5jMeBui5YNTWdNZ85hdEAdWlYEOtOlknIlMaUGljxvDazKDC36sFSpUHGTwR9Z70rFO 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: List-Subscribe: List-Unsubscribe: "Aneesh Kumar K.V" writes: > On 2/20/24 6:51 AM, Andrew Morton wrote: >> On Mon, 19 Feb 2024 14:04:23 +0530 Donet Tom wrote: >> >>>>> --- a/mm/mempolicy.c >>>>> +++ b/mm/mempolicy.c >>>>> @@ -2526,7 +2526,7 @@ int mpol_misplaced(struct folio *folio, struct vm_area_struct *vma, >>>>> if (node_isset(curnid, pol->nodes)) >>>>> goto out; >>>>> z = first_zones_zonelist( >>>>> - node_zonelist(numa_node_id(), GFP_HIGHUSER), >>>>> + node_zonelist(thisnid, GFP_HIGHUSER), >>>>> gfp_zone(GFP_HIGHUSER), >>>>> &pol->nodes); >>>>> polnid = zone_to_nid(z->zone); >>>> int thisnid = cpu_to_node(thiscpu); >>>> >>>> Is there any dofference between numa_node_id() and >>>> cpu_to_node(raw_smp_processor_id())? And it it explicable that we're >>>> using one here and not the other? >>> >>> Hi Andrew >>> >>> Both numa_node_id() and cpu_to_node(raw_smp_processor_id()) return the current execution node id, >>> Since the current execution node is already fetched at the beginning (thisnid) we can reuse it instead of getting it again. >> >> Sure, but mine was a broader thought: why do we have both? Is one >> preferable and if so why? > > IIUC these are two helpers to fetch current numa node id. and either of them can be used based on need. The default implementation shows the details. > (One small difference is numa_node_id() can use optimized per cpu reader because it is fetching the per cpu variable of the currently running cpu.) > > #ifndef numa_node_id > /* Returns the number of the current Node. */ > static inline int numa_node_id(void) > { > return raw_cpu_read(numa_node); > } > #endif > > #ifndef cpu_to_node > static inline int cpu_to_node(int cpu) > { > return per_cpu(numa_node, cpu); > } > #endif > > In mpol_misplaced function, we need the cpu details because we are using that in other place (should_numa_migreate_memory()). So it makes it easy > to use cpu_to_node(thiscpu) instead of numa_node_id(). IIUC, numa_node_id() is faster than cpu_to_node(thiscpu), even if we have thiscpu already. cpu_to_node() is mainly used to get the node of NOT current CPU. So, IMHO, we should only use numa_node_id() in this function. -- Best Regards, Huang, Ying