Re: [PATCH v4 06/20] sched/core: allow only preferred CPUs in is_cpu_allowed

[Shrikanth Hegde]

Hi Prateek.

On 6/18/26 9:19 AM, K Prateek Nayak wrote:
> Hello Shrikanth,
>
> On 6/17/2026 11:11 PM, Shrikanth Hegde wrote:
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -1657,6 +1657,7 @@ struct task_struct {
> >   #ifdef CONFIG_UNWIND_USER
> >   	struct unwind_task_info		unwind_info;
> >   #endif
> > +	int				has_preferred_cpu_state;
>
> Since this only really needs 2 bits, perhaps you can use the "u8 __pad"
> in the task struct? ...
>
> >   
> >   	/* CPU-specific state of this task: */
> >   	struct thread_struct		thread;
>
> [...snip...]
>
> > @@ -3549,6 +3568,14 @@ static int select_fallback_rq(int cpu, struct task_struct *p)
> >   	enum { cpuset, possible, fail } state = cpuset;
> >   	int dest_cpu;
> >   
> > +	/*
> > +	 * Cache value whether task's affinity spans preferred CPUs.
> > +	 * This helps to avoid repeating the same for each CPU
> > +	 * later in the loop. Encode call to is_cpu_allowed coming
> > +	 * via select_fallback_rq.
> > +	 */
> > +	p->has_preferred_cpu_state = task_has_preferred_cpus(p) << 8 | 0x1;
>
> ... Or maybe it can be an s8 and this indicator can be a tri-state like:
>
>   -1:  Cached; preferred CPUs exists
>    0:  preferred CPUs not cached
>    1:  Cached; preferred CPUs don't exist

Yes. Current encoding has.

1. call came from select_fallback_rq and preferred CPUs exists
2. call came from select_fallback_rq and preferred CPUs doesn't exists
3. Call didn't come from select_fallback_rq and evaluate the cpumask_interesect.

> and then the comparison can simply be:
>
>      if (cached)
>          return cached < 0;
>
> ppc64le and arm64 seems to generates slightly smaller code for "< 0"
> check compared to the current scheme of (& + >>) in
> task_has_preferred_cpus().

Yes, this seems better. I will give it a try.