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 DFD6E38A733 for ; Tue, 31 Mar 2026 10:01:26 +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=1774951288; cv=none; b=YzvDzvGNsQfkolh5CZq5PFNovq1CvZaIyCzkA2F0wGi7ictGsuY5mhTYN/h4Tgnvgd0ZNM7O8yY3lSzCvne7LfWg62bRQBjc2FuN9jcMPTT1QOlEEqNXruVnSTPfZgfqNg3iXw/fbxbDluvaBM641PX5NhAfHjqe+3mqCXx4AnQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774951288; c=relaxed/simple; bh=jrnsq3+adK+T1pcYfl4ycv6MoiI5JHV2w36N+0NZf64=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=rMWDqxZk41icEfJcT8xVVEc4Pv4t30tBwz69VcOY0t+jdr5/P3eMmUSk80pl1/iwBCEm07c1YKaYfj+zd/nj4yqz4FZwo0MWyNdnhmtgfEmg7ZqwR7wrlvSXlMudechDMNtsffTzS1Y7wz+TQZcjxoHAoG4H3gha/r98xAg1H+o= 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=hcdgPHMY; 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="hcdgPHMY" Received: from pps.filterd (m0353725.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 62V7nwQS057294; Tue, 31 Mar 2026 10:00:59 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=Cfp9sj 8bzWBMlYeri8cK26Hxagi+Z/bHu6P5bCVBtAk=; b=hcdgPHMYDIupXlIGZmIdar 5I/NCSHQASaxK9JkG4NCSHwsfkZ1Ao/GQFTdG4KbucKglM4vgJqsL6dmsaul3QHb 6xP9g6LFtSqcSeGKPbdX4NX1gbE0tzeyMik5TaKcQQ5iGXt923tkmf+cFHHraTg2 c9ld0G8IU1U90PSUl3G1BY89FqVh0yssrODKc3ja2mPaOe3hNpRkO/TxFDfVl6F4 oX1ScU7a0zYsRkZ3YR3IjQACZoOhLmhieMS0lIibOC4Wei8zvx+DnWOJSF6smTrr MuC9YZNy0p2ZYT7W4+bhkcABOzpcQPm4ADYHOZTJkEuM99h2VTpNAZr7VDO+7QJg == 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 4d65dca7ef-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Mar 2026 10:00:58 +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 62V7qX5E030952; Tue, 31 Mar 2026 10:00:58 GMT Received: from smtprelay04.dal12v.mail.ibm.com ([172.16.1.6]) by ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 4d6uhjr9yk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Mar 2026 10:00:58 +0000 Received: from smtpav01.dal12v.mail.ibm.com (smtpav01.dal12v.mail.ibm.com [10.241.53.100]) by smtprelay04.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 62VA0v4U28115548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 31 Mar 2026 10:00:57 GMT Received: from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9757858057; Tue, 31 Mar 2026 10:00:57 +0000 (GMT) Received: from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C4B3B58063; Tue, 31 Mar 2026 10:00:52 +0000 (GMT) Received: from [9.39.16.245] (unknown [9.39.16.245]) by smtpav01.dal12v.mail.ibm.com (Postfix) with ESMTP; Tue, 31 Mar 2026 10:00:52 +0000 (GMT) Message-ID: <207228fb-a4ee-460d-98e5-589187968b97@linux.ibm.com> Date: Tue, 31 Mar 2026 15:30:51 +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: "Huang, Ying" Cc: "David Hildenbrand (Arm)" , Andrew Morton , Ingo Molnar , Peter Zijlstra , 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> <2b8f30a6-a8d1-4ea5-8078-5eec399c8609@linux.ibm.com> <87cy0kpfdx.fsf@DESKTOP-5N7EMDA> <875x6cpddd.fsf@DESKTOP-5N7EMDA> Content-Language: en-US From: Donet Tom In-Reply-To: <875x6cpddd.fsf@DESKTOP-5N7EMDA> 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-Authority-Analysis: v=2.4 cv=RsjI7SmK c=1 sm=1 tr=0 ts=69cb9b5b 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=V8glGbnc2Ofi9Qvn3v5h:22 a=VnNF1IyMAAAA:8 a=wirRZfjEyRCDJu0qy4UA:9 a=QEXdDO2ut3YA:10 X-Proofpoint-GUID: wkBRYBN92QUNJAcDZjrV2VwhL-rXr_A1 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzMxMDA5NCBTYWx0ZWRfXys+ZPnaAfCCw pPVt76hIttmE1P78GFSTpZrzV4b5QNIMkbTJryLngcWTadnKywEPXZG3Ez2ifWxDyJ0VvKykrNI eS8H4vs4ZFr+egR4UOuunsNwLuYOY/n6pbX4mOngOwGmbXPluxXHXrrt7UVpbUe4lXPe3ep7jq3 BZYKTaW3Z9br5/09J+jxUL8pQ70W4jK8ntZbIf0WWGbxJepVEAADgwasC1y2aIDKjNiq8z0ExAR GjM3NQ3ZvQL9lR2vedH7OUDJgJDGJK9OoFkpgVG5TXqe3sf9K2twEHyFY8vjdAdrcgYATHp6fHJ obnriFpiqAzxrIzsHrBj5mkvillu9PKtHUpc5DsMSNRHqzoCHBe0m9M5dg5ba7qKb1osO0nG5z2 mT/DgfRmLxOf8Z3ZW52Z1slgbp3+JesLdPeSpBzwlit0Bsll0T1Q7d5PP6q0WUgD+QlTi1NoTYM 7V2HZWvnXIrmur1nX/A== X-Proofpoint-ORIG-GUID: ub8R7S2hHL24WwRtIqsPlwgRs8Aoal_U 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-31_02,2026-03-28_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 bulkscore=0 priorityscore=1501 lowpriorityscore=0 suspectscore=0 malwarescore=0 spamscore=0 clxscore=1015 phishscore=0 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2603050001 definitions=main-2603310094 On 3/31/26 2:47 PM, Huang, Ying wrote: > Donet Tom writes: > >> Hi >> >> On 3/31/26 2:03 PM, Huang, Ying wrote: >>> Hi, Donet, >>> >>> Donet Tom writes: >>> >>>> 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 >>> It can be less than 21 bits, if CONFIG_NR_CPUS is small. >>> >>> DEFINE(NR_CPUS_BITS, order_base_2(CONFIG_NR_CPUS)); >>> >>>> 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. >>> Yes. IMHO, false positives is unavoidable. So, the patch fixes a >>> temporal performance issue at the cost of a longstanding performance >>> issue. Right? >> >> I was trying to fix a functional issue. When memory tiering is >> >> enabled at runtime, treating last_cpupid as access time is incorrect, right? > I don't think that it's a functional issue. It has only performance > impact. Did you find any functionality bug? > Thank you for the confirmation. I thought this was a functional issue. In that case, we can drop this patch. -Donet > > --- > Best Regards, > Huang, Ying