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 539A1C48BC3 for ; Tue, 20 Feb 2024 07:04:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DC6E06B0078; Tue, 20 Feb 2024 02:04:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D76AB6B007B; Tue, 20 Feb 2024 02:04:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C3E426B007D; Tue, 20 Feb 2024 02:04:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id B41A86B0078 for ; Tue, 20 Feb 2024 02:04:07 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7E3BB160584 for ; Tue, 20 Feb 2024 07:04:07 +0000 (UTC) X-FDA: 81811292934.25.F140C9C Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf15.hostedemail.com (Postfix) with ESMTP id 12F64A0012 for ; Tue, 20 Feb 2024 07:04:04 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Zi6tPaWa; spf=pass (imf15.hostedemail.com: domain of aneesh.kumar@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=aneesh.kumar@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708412645; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KdOjHjiupR+ABzI1zHhISTUtJTjf45sXi6PmRiZ+npk=; b=NZ+OAId0Pk4qA7V2uHijsQFz501gkF6jW/LGwYU2/nsAkLNaWvY8NtvwqnTjwigmO+W0IK +KL/k0d1lk7pYWfDr47XfqdzwX3k2rKn6qBOVO53xdbudXezAjsTonIHef+rFaPEdV1Yrm B8kIR3NMnpmwrARt0Di2R7gfzFxlCq0= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Zi6tPaWa; spf=pass (imf15.hostedemail.com: domain of aneesh.kumar@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=aneesh.kumar@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708412645; a=rsa-sha256; cv=none; b=mUHeuZqqEZAl8APuZoLXNWEhXRl0dM+b44gkCAF+aOdKZDMU7XuusLvy4QRgbLO/MTHQCe Zc3Y2tXQqe11zY01zW+5IdLeKOqVpEAHFJ1uzqv2q5UPV6ps2IxGy0WSjCEIMTKafOoefB J9WazrXTieBVh0uwo+8E9MFV2FH8icQ= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 7858ECE13E1; Tue, 20 Feb 2024 07:04:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 61638C433C7; Tue, 20 Feb 2024 07:03:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708412640; bh=PMQoz8O5HTzQHK/8qIlXhgJEFRcEgbpMwCdJThDc+fw=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=Zi6tPaWauef5T/Nrx1WvQcsey8zBCfJYKhuNwG4sQVYWSgEn4RyMBl1F2VIw/qSHc TPvDCayTZeuLIBnW9CapdThhB5qgi9Wx6l+ub9jpClL9IhO0+nfGkGNAldSOLlk+SY Vu3n1T/jP9+re25D1PeOen5sX+lktNX7f6TBb/7jS7jFGiu+NwvldGNnBTijzy+wRl gLwNabtb+XH6AJmMeHNnZxc/cKi000RPpKfksdoi2faTxZucxAHLA9pR/JdiPLZceV PfZHT0G47zBC4gTe3NArvuVNU5Qj2TQKOMJXj+LjpIj5QYaC9uLIRxskAB5sEKsFi1 L/CbHRRFRQOCw== Message-ID: Date: Tue, 20 Feb 2024 12:33:51 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/3] mm/mempolicy: Use the already fetched local variable Content-Language: en-US From: "Aneesh Kumar K.V" To: "Huang, Ying" 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 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> <87frxnps8w.fsf@yhuang6-desk2.ccr.corp.intel.com> <7097ff95-6077-4744-a770-b90d224c0c9b@kernel.org> In-Reply-To: <7097ff95-6077-4744-a770-b90d224c0c9b@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 12F64A0012 X-Rspam-User: X-Stat-Signature: thuu9kdsrmhfpmysg8ctq8635sp35k6n X-Rspamd-Server: rspam01 X-HE-Tag: 1708412644-250888 X-HE-Meta: U2FsdGVkX19R/pY3fX60Ufz9c8aLn2OGJHjn9Z7XmMKM80V33fttHdej89iJcuQ/vkiKofj1v0XbQ0XoQo6ey4p/fqpIX3pAJq+t+xrFQVUVNArQEei2LlngaFDF3KkdDTptRQ/6TgJBVwD9kNfEPtASjzkGoWjhPU2RK7YzjAnJjp4ZwC8b463KWYTBGWjjr9H5sf3uPI4ruHedcOLV2+pMNyMTvMUVEdVZrj1zWvegqcuyF+P9Gp51VVKZBezVbE++el1FLh97l6UjrdYQlqyi6oZt9E4xXBL8FMfkEad8pc09iRnhX6uyzbfDy/AX1+fQzfZ/3WUYBO6hGpt5NmzqUoi6YnxcskXBCclN9OT8bG0IxxeAP8DaakqKpS1p45k2esZ/AyJHmRwwVIOWW8AyN6Y0OkZoierfl6fC5YQnripQc3wITmBUKIFB2PI2OdntvzqKahNI53PmgNcByk4hNF9y2TW6bG5lVI3qfaoVC3hKSCmC+lh+yVldiVxzCEhsBYAbwf3zIpjOxsnPd1FUA/cb4tXK535zgEMxKrZaGetdEuV+bUAYO1wOPrmkPqBYGmkHTegPJu8keQghhjGRW82wWuvMx5Q5LtERMYastWIWkXBEgicbwbu69gw7fx4L6VYOPOxJVFNpj1VNCKyfkOs6ZEK5I5BJd/XsSIU1gS8bbauiKBnc5RjXF12PTDdJ0q8TnK2MRYBtaqTRJHHEZnwstwoVRT9jDP7lueyqMJFdPvR+kpoXVtE2hoHUQRMHEI/ZHwNJ4o9sodyY66o20V9hZIhS1wBCgfRItOwMDhOEodj4tBM6TPTDFEMJOWOPtcWSVLGQLFDnI/s4JlWetLEeGeIOXDMsiBA8saxoiPqOVDMral0HJvK9BZ3hcnvD4vqPYUwVhRR3/ns5Fy6nPKRd0vAZz5FqZqoOlmUykQJwrID/LRpDAorVpWjv0/YNnYr/VDehrDg+IDN MnFBZTkq ukxnwHXpKSmvqRVYTFjipTBU1A/+wVWPPia+X/efown5icn6PJ4hLz8JR4WVco0MbBq2OqEti8d/JRDZxBtJiIB37CSUzPKgQkHb26DPQxun5sDGZVoaAi2UzMeeMbrlU33/G8tJSIBILL9vv9MTOkgfpB58Sj3rmOfphc6BnEKcnySh5w/DRisPhCcFDohwCpc2HEWfrzf5q0x/oViAhzWaN/gpEv2+7+xYJ/g8Fu0UBbKJKxq48g4Cfb5+1vFI3q6bMQPeVQVcgZp8L3xov0wn8nUCT5aBdnGf0Fn1vdyYjK3GKAPyfA6y3FA== 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: On 2/20/24 12:02 PM, Aneesh Kumar K.V wrote: > On 2/20/24 11:55 AM, Huang, Ying wrote: >> "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. >> > > This change? > > modified mm/mempolicy.c > @@ -2502,8 +2502,7 @@ int mpol_misplaced(struct folio *folio, struct vm_area_struct *vma, > pgoff_t ilx; > struct zoneref *z; > int curnid = folio_nid(folio); > - int thiscpu = raw_smp_processor_id(); > - int thisnid = cpu_to_node(thiscpu); > + int thisnid = numa_node_id(); > int polnid = NUMA_NO_NODE; > int ret = NUMA_NO_NODE; > > @@ -2573,7 +2572,7 @@ int mpol_misplaced(struct folio *folio, struct vm_area_struct *vma, > polnid = thisnid; > > if (!should_numa_migrate_memory(current, folio, curnid, > - thiscpu)) > + raw_smp_processor_id())) > goto out; > } > > One of the problem with the above change will be the need to make sure smp processor id remaining stable, which I am not sure we want in this function. With that we can end up with processor id not related to the numa node id we are using. -aneesh