Re: [PATCH] sched/numa, mm: Skip page promotion if cpu pid is valid

[Donet Tom]

On 3/31/26 3:34 PM, David Hildenbrand (Arm) wrote:
> On 3/31/26 10:33, Huang, Ying wrote:
> > Hi, Donet,
> >
> > Donet Tom <donettom@xxxxxxxxxxxxx> writes:
> >
> > > On 3/26/26 3:59 PM, David Hildenbrand (Arm) wrote:
> > > > Is that measurable? Should we at least have a Fixes: ?
> > > >
> > > > /*
> > > >    * When ...
> > > >
> > > > 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?
>
> Could we set aside a bit to indicate "cpuid vs. time" ? We'd lose one
> bit for time, to we care?


Thank you, David, for the input. This sounds like a good idea—I'll give 
it a try.

-Donet


> Would make it all easier to get ...