[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e1abcbde-252c-41cd-a018-c8222cb0661a@intel.com>
Date: Fri, 4 Jul 2025 23:00:02 +0800
From: "Chen, Yu C" <yu.c.chen@...el.com>
To: Shrikanth Hegde <sshegde@...ux.ibm.com>, Tim Chen
<tim.c.chen@...ux.intel.com>
CC: Juri Lelli <juri.lelli@...hat.com>, Dietmar Eggemann
<dietmar.eggemann@....com>, Steven Rostedt <rostedt@...dmis.org>, Ben Segall
<bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>, Valentin Schneider
<vschneid@...hat.com>, Tim Chen <tim.c.chen@...el.com>, Vincent Guittot
<vincent.guittot@...aro.org>, Libo Chen <libo.chen@...cle.com>, Abel Wu
<wuyun.abel@...edance.com>, Madadi Vineeth Reddy <vineethr@...ux.ibm.com>,
Hillf Danton <hdanton@...a.com>, Len Brown <len.brown@...el.com>,
<linux-kernel@...r.kernel.org>, Peter Zijlstra <peterz@...radead.org>, "Ingo
Molnar" <mingo@...hat.com>, K Prateek Nayak <kprateek.nayak@....com>,
"Gautham R . Shenoy" <gautham.shenoy@....com>
Subject: Re: [RFC patch v3 10/20] sched: Calculate the number of tasks that
have LLC preference on a runqueue
On 7/4/2025 3:45 AM, Shrikanth Hegde wrote:
>
>
> On 6/18/25 23:57, Tim Chen wrote:
>> Track for each run queue, the number of tasks that have a LLC preference
>> and how many of those tasks are running in its preferred LLC. This is
>> similar to nr_numa_running and nr_preferred_running for NUMA balance,
>> and will be used by the cache-aware load balancing in subsequent patches.
>>
>> Signed-off-by: Tim Chen <tim.c.chen@...ux.intel.com>
>> ---
>> kernel/sched/core.c | 12 ++++++++++++
>> kernel/sched/fair.c | 42 +++++++++++++++++++++++++++++++++++++++++-
>> kernel/sched/sched.h | 7 +++++++
>> 3 files changed, 60 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index d9c3e75f79d1..34056eb79ef2 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -498,6 +498,18 @@ void __trace_set_current_state(int state_value)
>> }
>> EXPORT_SYMBOL(__trace_set_current_state);
>> +#ifdef CONFIG_SMP
>
>
> CONFIG_SMP is true unconditionally now. Else may need to go.
>
OK. I suppose it will take effect from 6.17? We can remove this control
after rebasing to that version.
thanks,
Chenyu
Powered by blists - more mailing lists