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

[Shrikanth Hegde <sshegde@linux.ibm.com>]

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.