Re: [PATCH 08/19] sched/fair: Introduce per runqueue task LLC preference counter

["Chen, Yu C" <yu.c.chen@intel.com>]

On 10/21/2025 4:28 PM, Madadi Vineeth Reddy wrote:
> On 16/10/25 02:11, Tim Chen wrote:
>> On Wed, 2025-10-15 at 14:21 +0200, Peter Zijlstra wrote:
>>> On Sat, Oct 11, 2025 at 11:24:45AM -0700, Tim Chen wrote:
>>>> Each runqueue is assigned a static array where each element tracks
>>>> the number of tasks preferring a given LLC, indexed from 0 to
>>>> NR_LLCS.
>>>>
> 
> [snip]
> 
>>>
>>>>   
>>>> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
>>>> index 3ab64067acc6..b801d32d5fba 100644
>>>> --- a/kernel/sched/sched.h
>>>> +++ b/kernel/sched/sched.h
>>>> @@ -1101,6 +1101,7 @@ struct rq {
>>>>   #ifdef CONFIG_SCHED_CACHE
>>>>   	unsigned int		nr_pref_llc_running;
>>>>   	unsigned int		nr_llc_running;
>>>> +	unsigned int		nr_pref_llc[NR_LLCS];
>>>
>>> Gah, yeah, lets not do this. Just (re)alloc the thing on topology
>>> changes or something.
>>
>> Will have to think about how to keep the tasks' preference
>> consistent with nr_pref_llc with the new array.  Perhaps
>> make it size of NR_CPUS so we will allocate
>> once and don't have to resize and reallocate it, and
>> fill it back up with the right data.
>>
>> Tim
> 
> IIUC, what Peter meant is to dynamically allocate the array size based on
> the actual number of LLCs computed in build_sched_domains() or somesuch
> rather than statically allocating NR_LLCS which is 64 by default.
> 

OK, this might involve dynamic adjustment/data synchronization of the
nr_pref_llc buffer during CPU hotplug, and we'll make some modifications 
to it.

thanks,
Chenyu

> Making it NR_CPUS would be even larger and waste more memory on systems
> with few LLCs.
> 
> Thanks,
> Madadi Vineeth Reddy