From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 533B2218ADA for ; Thu, 9 Jan 2025 14:29:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.158.5 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736432990; cv=none; b=vCAVa+bSukuICETHj4HrgH9ukBAjVxhnIr3+6vxD5q1xzvw1MuNqKxCotwRFt5etKVpqTudHveMzq6vvRE96ry2oC7soRgdtdb+KG4S3BLUmhBWzuia8Z47kwQwAVMTKU3VnPoB0VWleexEFYuA6HGIf64maoENv/g+TCFdNL7M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736432990; c=relaxed/simple; bh=I/OOULYBE5FwCC6+0JyXyKjxesWYxsDlT7TYAejelOg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=bOdKpQJZlFpJYPQ7OLv+fXB+QavAXdlWiS1veSa9wYC+Ul0k+715seYCd8UBelk9veNW5ds7BTqRb+JH+i2VYd35CWTaFrf/KbeS2aEikysF3c2zzRD6EHibUtpEaz77+mUAC1agC8gVIftZmq88PsklXH0tNOxvcmpnXppgzO8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=jafkBlRG; arc=none smtp.client-ip=148.163.158.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="jafkBlRG" Received: from pps.filterd (m0353725.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 509E6UZb010315; Thu, 9 Jan 2025 14:29:35 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=pp1; bh=DbH9Fv x918DTHwYhU+DbowEBjDcXJXxs2Ftr9Np8WUo=; b=jafkBlRGIu5Ivj6puIqtQE j0h1I93/ZM1v/N2uEs8PaQI/mzVZJGqCGHv4kADoQH9gJfM7eQICS0NaErpVQwpw cXSeBUzLoCLZexWjTuQ+Op+Y2NiA3QifVJMQDh/l//znDnuWt5BCn6Q5o2+NXtUZ XgT7wKXthfXZaXsWvZ8llp9z/AWhGHYKINHUsSzrFaT5wUW6MOfMSTmsIqnzg3Tw gX142APOiVAxe6j9cLCt0kCmtPittv056/L+ywo9hBPAoms3qwB9mfC6fgMGHF/c TwmkEF3sXFbDaBymW9m+u8SPxMm72CenYhFjRiYRdjmlZe5IifD91Y1b5gqKDh5w == Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 442fx583fk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Jan 2025 14:29:35 +0000 (GMT) Received: from m0353725.ppops.net (m0353725.ppops.net [127.0.0.1]) by pps.reinject (8.18.0.8/8.18.0.8) with ESMTP id 509EHx87008711; Thu, 9 Jan 2025 14:29:35 GMT Received: from ppma13.dal12v.mail.ibm.com (dd.9e.1632.ip4.static.sl-reverse.com [50.22.158.221]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 442fx583ep-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Jan 2025 14:29:34 +0000 (GMT) Received: from pps.filterd (ppma13.dal12v.mail.ibm.com [127.0.0.1]) by ppma13.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 509DvkfL027929; Thu, 9 Jan 2025 14:29:15 GMT Received: from smtprelay04.wdc07v.mail.ibm.com ([172.16.1.71]) by ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 43yhhkd9c6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Jan 2025 14:29:15 +0000 Received: from smtpav04.wdc07v.mail.ibm.com (smtpav04.wdc07v.mail.ibm.com [10.39.53.231]) by smtprelay04.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 509ETEMn49938820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 9 Jan 2025 14:29:15 GMT Received: from smtpav04.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DDC3558056; Thu, 9 Jan 2025 14:29:14 +0000 (GMT) Received: from smtpav04.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 65DDF58045; Thu, 9 Jan 2025 14:29:11 +0000 (GMT) Received: from [9.109.245.146] (unknown [9.109.245.146]) by smtpav04.wdc07v.mail.ibm.com (Postfix) with ESMTP; Thu, 9 Jan 2025 14:29:11 +0000 (GMT) Message-ID: <1a384b0d-0548-4340-a664-dffe8fe4cbdc@linux.ibm.com> Date: Thu, 9 Jan 2025 19:59:10 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/memory.c: Add return NUMA_NO_NODE in numa_migrate_check() when folio_nid() and numa_node_id() are the same. To: David Hildenbrand , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Ritesh Harjani , Baolin Wang , "Aneesh Kumar K . V" , Matthew Wilcox , Zi Yan , Muchun Song References: <20250109064632.898260-1-donettom@linux.ibm.com> Content-Language: en-US From: Donet Tom In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: auFNoWxJ8BdxPTYsNUmtFzrfBt-BuycR X-Proofpoint-ORIG-GUID: FdGadtJ24jv4vx59y_DH8K4PQrkvH_ou X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1051,Hydra:6.0.680,FMLib:17.12.62.30 definitions=2024-10-15_01,2024-10-11_01,2024-09-30_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 clxscore=1015 spamscore=0 suspectscore=0 impostorscore=0 phishscore=0 priorityscore=1501 mlxlogscore=935 bulkscore=0 lowpriorityscore=0 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2411120000 definitions=main-2501090116 On 1/9/25 18:43, David Hildenbrand wrote: > On 09.01.25 07:46, Donet Tom wrote: >> If the folio_nid() and numa_node_id() are the same, it indicates >> that the folio is already on the same node as the process. In >> this case, there's no need to migrate the pages. >> >> This patch adds return NUMA_NO_NODE in numa_migrate_check() when >> the folio_nid() and numa_node_id() match, preventing the function >> from executing the remaining code unnecessarily. >> >> Signed-off-by: Donet Tom >> --- >>   mm/memory.c | 1 + >>   1 file changed, 1 insertion(+) >> >> diff --git a/mm/memory.c b/mm/memory.c >> index 398c031be9ba..dfd89ff7f639 100644 >> --- a/mm/memory.c >> +++ b/mm/memory.c >> @@ -5509,6 +5509,7 @@ int numa_migrate_check(struct folio *folio, >> struct vm_fault *vmf, >>       if (folio_nid(folio) == numa_node_id()) { >>           count_vm_numa_event(NUMA_HINT_FAULTS_LOCAL); >>           *flags |= TNF_FAULT_LOCAL; >> +        return NUMA_NO_NODE; > > Doesn't this just mean that it is a local fault, but not necessarily > that we don't want to migrate that folio? > > mpol_misplaced states: "check whether current folio node is valid in > policy" > > Could we have a different policy set that does not indicate the local > node as the target node? > > Note how mpol_misplaced() obtains the target node to the do > > > int curnid = folio_nid(folio); > ... > int polnid = NUMA_NO_NODE; > int ret = NUMA_NO_NODE > > ... detect polnid > > if (curnid != polnid) >     ret = polnid; > ... > return ret; > > > So mpol_misplaced() will return "NUMA_NO_NODE" if already on the > correct target node. Thank you, David. I understood my patch is wrong. I have a small question: Page access latency is lower when the folio is on the same NUMA node as the process. However, if the policy node is set to a different NUMA node and the MPOL_F_MORON flag is not set, we migrate the page to the policy node, thereby increasing access latency.  Could this have an impact on performance? What benefits do we gain from this?