From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (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 34C59330330 for ; Fri, 27 Mar 2026 18:54:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.156.1 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774637692; cv=none; b=OE7LfYoBlwcP+LJVtu9gfrvBw9+UkaAV/Ik3aJCDLRMRL0leqikLCJO/zgX8tEEWwUlWJjUIChdQjPMSDUEowR1iu5HzK/2G+Y5M7pzpg3ysBAN5NZszvUj7u4pUfI97owPU31UkNLIMYa0BZXRxpjBSuMpn/uI8sYmSLbb+YFw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774637692; c=relaxed/simple; bh=zsEw+uUPhsFCnYvCpmxQnI69FKHmRFn6yHyQjwPfMTQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=CexgIbyuPc71Q8EnCG0R+pCvolSTKGBppjCifmlTFuGbRFa4KlJbt8pCPqW80bXib0Rld0bVuYxv1A89X82Q918r6ogwAc6ARHxvzd2opFHp4B9ml96MDEG8M4bvsd0eVFXMC3wi0QNC475lnv30lPpyeorzzstFxS39F95zQQ0= 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=VlwS5Xz1; arc=none smtp.client-ip=148.163.156.1 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="VlwS5Xz1" Received: from pps.filterd (m0360083.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 62RAKCmi3275715; Fri, 27 Mar 2026 18:54:22 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=TlW9BN NRrexZjfCFbEEazoVNUBAQydVdjXTuEnMtgLs=; b=VlwS5Xz1eb1XJB5F1ypZ0J 9A1jl/b8Q23mq/zP467Sgxa8SYnVxeS6EGGYVDhD4ne0KjjGBft3ZwxQiCsosjUp jkWCuRDEdBEqgs+F/9O5Zn6WUzXTrP6Lf70weMyzXLKR070e1WLkRejgtDl1vwGF RgFqiOJ/lBksQWBkFKYywInxaq+yKv+nl2IeS5/bfiEcnriAY4y1aZRVroQrKm+Y tUQvW4/uO7AsZZyYYTBC9SkOCvXcq9W0S5gP5RcpGinPpz1yZwuF9odd/KyS3uQu YdU+WYZkb+S46HMDLIkUcbUVqiaMAfBAVMwCB4nbwS9WHRWZ+12NbBoUIAwJRYbg == 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 4d1kxqus7f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Mar 2026 18:54:22 +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 62RGAsfU012203; Fri, 27 Mar 2026 18:54:21 GMT Received: from smtprelay05.dal12v.mail.ibm.com ([172.16.1.7]) by ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 4d27vkgmen-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Mar 2026 18:54:21 +0000 Received: from smtpav05.wdc07v.mail.ibm.com (smtpav05.wdc07v.mail.ibm.com [10.39.53.232]) by smtprelay05.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 62RIsKpS22479412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 27 Mar 2026 18:54:20 GMT Received: from smtpav05.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5C49B58059; Fri, 27 Mar 2026 18:54:20 +0000 (GMT) Received: from smtpav05.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9C94358043; Fri, 27 Mar 2026 18:54:15 +0000 (GMT) Received: from [9.39.31.223] (unknown [9.39.31.223]) by smtpav05.wdc07v.mail.ibm.com (Postfix) with ESMTP; Fri, 27 Mar 2026 18:54:15 +0000 (GMT) Message-ID: <2b8f30a6-a8d1-4ea5-8078-5eec399c8609@linux.ibm.com> Date: Sat, 28 Mar 2026 00:24:13 +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] sched/numa, mm: Skip page promotion if cpu pid is valid To: "David Hildenbrand (Arm)" , Andrew Morton , Ingo Molnar , Peter Zijlstra Cc: Ritesh Harjani , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Baolin Wang , Ying Huang , Juri Lelli , Mel Gorman , Vincent Guittot , Dietmar Eggemann , Steven Rostedt References: <20260326071216.11883-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: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-Reinject: loops=2 maxloops=12 X-Proofpoint-ORIG-GUID: pdv13f44JNz3stscr6j05sOF31-2DWb9 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzI3MDEzMSBTYWx0ZWRfX2/IxKQ9ywZxb 6o8XoOI0Z83QeKc4khNcjLT2lRbR0EUv9ahso6ncL388JkD/vfqbM3NPD050/A188WTWRw1+egW 0RS/eQa6vwOMYS16v2Ob5cO7sK0THeBY0EwUjMHVlz3eYCJusGWg6MUTPdsCdYxAPbu9h8wCxCw ZaxrzRK8WspjmnptyPWR571pfocGgCFUOgZGcYMc2NVxO+FkFIimFQRq+8wRw0emfRD8ZPFn8x8 QpSgP8Fx4kWv3qLl92gTAU+smFGqlhtB/vmVIUbUV0G5v9ur4gCgclUv9EzeU3yxb23JcY93w87 QOer/ZEaqwh1XS8qnwyERZD9WkRH/6RiYnBIFLupzaLwkgjYPUmnav9rZMkTggJILaHGXQdTZLB 5+z6x9oeJU5X+qOoaxG/YZ5uoyf/4Tipe1tOnHrJmW/2HFWjZt4RS65K9PxfQfIZMPpB39Nh19W pS75i5gHk3elfQqo5WQ== X-Authority-Analysis: v=2.4 cv=bLEb4f+Z c=1 sm=1 tr=0 ts=69c6d25e cx=c_pps a=AfN7/Ok6k8XGzOShvHwTGQ==:117 a=AfN7/Ok6k8XGzOShvHwTGQ==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=iQ6ETzBq9ecOQQE5vZCe:22 a=VnNF1IyMAAAA:8 a=VwQbUJbxAAAA:8 a=ZNc9nmATnA53SlO39hEA:9 a=QEXdDO2ut3YA:10 X-Proofpoint-GUID: ccn_TVv-MI4uN9Z2uHN8TvsWLjm1Z48f X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-27_01,2026-03-26_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 adultscore=0 clxscore=1015 phishscore=0 impostorscore=0 malwarescore=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 priorityscore=1501 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2603050001 definitions=main-2603270131 On 3/26/26 3:59 PM, David Hildenbrand (Arm) wrote: > On 3/26/26 08:12, Donet Tom wrote: >> If memory tiering is disabled, cpupid of slow memory pages may >> contain a valid CPU and PID. If tiering is enabled at runtime, >> there is a chance that in should_numa_migrate_memory(), this >> valid CPU/PID is treated as a last access timestamp, leading >> to unnecessary promotion. > Is that measurable? Should we at least have a Fixes: ? > >> Prevent this by skipping promotion when cpupid is valid. >> >> Signed-off-by: Donet Tom >> --- >> kernel/sched/fair.c | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >> index 4b43809a3fb1..f5830a5a94d5 100644 >> --- a/kernel/sched/fair.c >> +++ b/kernel/sched/fair.c >> @@ -2001,6 +2001,13 @@ bool should_numa_migrate_memory(struct task_struct *p, struct folio *folio, >> unsigned int latency, th, def_th; >> long nr = folio_nr_pages(folio); >> > /* > * When ... > >> + /* When tiering is enabled at runtime, last_cpupid may >> + * hold a valid cpupid instead of an access timestamp. >> + * If so, skip page promotion. >> + */ >> + if (cpupid_valid(folio_last_cpupid(folio))) >> + return false; >> + > IIUC, as timestamp we use jiffies_to_msecs(). So, soon after bootup, > we would no longer get false positives for cpupid_valid(). > I suppose overflows are not a problem, correct? Thank you, David, for guiding me in the right direction. I initially thought that overflows would not occur, and therefore cpupid_valid() would not produce false positives. However, after looking into it further, it appears that overflow can happen when storing the access time. The last_cpupid field is used to store the last access time. From the code, it appears that 21 bits are used for this (#define LAST_CPUPID_SHIFT (LAST__PID_SHIFT + LAST__CPU_SHIFT)). With 21 bits, the maximum value that can be stored is 2097151ms (35Hrs) . If the access time exceeds this range, it can overflow, which may lead to cpupid_valid() returning false positives. I think we need a reliable way to determine cpupid_valid() that does not produce false positives. -Donet > > So what we're saying is that folio_use_access_time()==true does not > imply that there is actually a valid time in there. > > In numa_migrate_check() we could still use the valid cpuid I guess and > make that code a bit clearer? > > diff --git a/mm/memory.c b/mm/memory.c > index 631205a384e1..ba68933a9e4a 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -6119,10 +6119,9 @@ int numa_migrate_check(struct folio *folio, struct vm_fault *vmf, > * For memory tiering mode, cpupid of slow memory page is used > * to record page access time. So use default value. > */ > - if (folio_use_access_time(folio)) > + *last_cpupid = folio_last_cpupid(folio); > + if (!cpupid_valid(*last_cpupid)) > *last_cpupid = (-1 & LAST_CPUPID_MASK); > - else > - *last_cpupid = folio_last_cpupid(folio); > > /* Record the current PID accessing VMA */ > vma_set_access_pid_bit(vma); > > > The change itself here looks reasonable to me. > > Acked-by: David Hildenbrand (Arm) >