From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-124.freemail.mail.aliyun.com (out30-124.freemail.mail.aliyun.com [115.124.30.124]) (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 C6B41395260 for ; Tue, 31 Mar 2026 08:33:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774946040; cv=none; b=W6X9sqLWMAx1WWOmuAeCZYpzOYmiPU81KTRbcuEnmn+7mTFbooU5ZP8hNzwq5Q4ZcYttzgx6+vAFyEeJuUPKpfGf5LRJLFM0hG5VzeTcZZWwFWyfnhdc3Z3U/wgUePFkCrz1fIdJ4OOXyLtHMo4YGqwNgl/lsYBMUw6bb8JEEpk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774946040; c=relaxed/simple; bh=ReFfjsy9eERFSK6xDO6mAt1SdIQp/UEE7QMhrT7qdrQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=XpS7CtwHVIuAMLel0MFwrlj8+S93W+2I/8T5L4KCTpq7MNFrO7yucI2vSuHAY0RaVyGrMq7SbRNKsKdptkneBPFYjLpe5ZxQIbZg9Kw110MTBBB+SZuBistUZHdGsJjqLddkErW4TPON4PLlXujqTqf8BV8F0e1UdaW+S0KmwkE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=WWRZgfiw; arc=none smtp.client-ip=115.124.30.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="WWRZgfiw" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1774946034; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=gV3wC6wNUStVNDdA5/n0gORLQ4zEznxAC2xRqMLlVrs=; b=WWRZgfiwiqRjclerUERliR7mwE/dSO5QHGggzczBW8KExil8TUtOYinZCZrz9ylg1JbKsyvJOlc4rZ9AsTFwKQAY6tR++Il19mN9KUaDR86n9CcBQFTNnwQ7jUc1ntdZ2C/bLtellDWsJIPStKl6zUK6zwQH+zde7mogmPURSt0= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R141e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037009110;MF=ying.huang@linux.alibaba.com;NM=1;PH=DS;RN=15;SR=0;TI=SMTPD_---0X03p4SA_1774946009; Received: from DESKTOP-5N7EMDA(mailfrom:ying.huang@linux.alibaba.com fp:SMTPD_---0X03p4SA_1774946009 cluster:ay36) by smtp.aliyun-inc.com; Tue, 31 Mar 2026 16:33:52 +0800 From: "Huang, Ying" To: Donet Tom 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 Subject: Re: [PATCH] sched/numa, mm: Skip page promotion if cpu pid is valid In-Reply-To: <2b8f30a6-a8d1-4ea5-8078-5eec399c8609@linux.ibm.com> (Donet Tom's message of "Sat, 28 Mar 2026 00:24:13 +0530") References: <20260326071216.11883-1-donettom@linux.ibm.com> <2b8f30a6-a8d1-4ea5-8078-5eec399c8609@linux.ibm.com> Date: Tue, 31 Mar 2026 16:33:30 +0800 Message-ID: <87cy0kpfdx.fsf@DESKTOP-5N7EMDA> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=ascii 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? --- Best Regards, Huang, Ying > >> >> 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) >>