linux-kernel - Re: [PATCH 15/19] sched/fair: Respect LLC preference in task migration and detach

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d1dc82c4-19d1-4897-b4a2-438512969868@amd.com>
Date: Wed, 29 Oct 2025 09:45:31 +0530
From: K Prateek Nayak <kprateek.nayak@....com>
To: Tim Chen <tim.c.chen@...ux.intel.com>, "Chen, Yu C" <yu.c.chen@...el.com>
CC: Vincent Guittot <vincent.guittot@...aro.org>, 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>, "Madadi Vineeth
 Reddy" <vineethr@...ux.ibm.com>, Hillf Danton <hdanton@...a.com>, "Shrikanth
 Hegde" <sshegde@...ux.ibm.com>, Jianyong Wu <jianyong.wu@...look.com>, Yangyu
 Chen <cyy@...self.name>, Tingyin Duan <tingyin.duan@...il.com>, "Vern Hao"
	<vernhao@...cent.com>, Len Brown <len.brown@...el.com>, Aubrey Li
	<aubrey.li@...el.com>, Zhao Liu <zhao1.liu@...el.com>, Chen Yu
	<yu.chen.surf@...il.com>, Adam Li <adamli@...amperecomputing.com>, Tim Chen
	<tim.c.chen@...el.com>, <linux-kernel@...r.kernel.org>, Peter Zijlstra
	<peterz@...radead.org>, "Gautham R . Shenoy" <gautham.shenoy@....com>, "Ingo
 Molnar" <mingo@...hat.com>
Subject: Re: [PATCH 15/19] sched/fair: Respect LLC preference in task
 migration and detach

Hello Tim,

On 10/28/2025 9:00 PM, Tim Chen wrote:
>>>> +#ifdef CONFIG_SCHED_CACHE
>>>> +		/*
>>>> +		 * Don't detach more tasks if the remaining tasks want
>>>> +		 * to stay. We know the remaining tasks all prefer the
>>>> +		 * current LLC, because after order_tasks_by_llc(), the
>>>> +		 * tasks that prefer the current LLC are at the tail of
>>>> +		 * the list. The inhibition of detachment is to avoid too
>>>> +		 * many tasks being migrated out of the preferred LLC.
>>>> +		 */
>>>> +		if (sched_cache_enabled() && detached && p->preferred_llc != -1 &&
>>>> +		    llc_id(env->src_cpu) == p->preferred_llc)
>>>> +			break;
>>>
>>> In all cases? Should we check can_migrate_llc() wrt to util migrated and
>>> then make a call if we should move the preferred LLC tasks or not?
>>>
>>
>> Prior to this "stop of detaching tasks", we performed a can_migrate_task(p)
>> to determine if the detached p is dequeued from its preferred LLC, and in
>> can_migrate_task(), we use can_migrate_llc_task() -> can_migrate_llc() to
>> carry out the check. That is to say, only when certain tasks have been
>> detached, will we stop further detaching.
>>
>>> Perhaps disallow it the first time if "nr_balance_failed" is 0 but
>>> subsequent failed attempts should perhaps explore breaking the preferred
>>> llc restriction if there is an imbalance and we are under
>>> "mig_unrestricted" conditions.
>>>
>>
> 
> Pratek,
> 
> We have to actually allow for imbalance between LLCs with task
> aggregation.
> 
> Say we have 2 LLCs and only one process running. Suppose all tasks in the process
> can fit in one LLC and not overload it. Then we should not pull tasks from
> the preferred LLC, and allow the imbalance. If we balance the tasks the
> second time around, that will defeat the purpose.
> 
> That's why we have the knob llc_overload_pct (50%), which will start spreading
> tasks to non-preferred LLC once load in preferred LLC excees 50%.
> And llc_imb_pct(20%), which allows for a 20% higher load between preferred LLC
> and non-preferred LLC if the preferred LLC is operating above 50%.
> 
> So if we ignore the LLC policy totally the second time around, we may be breaking
> LLC aggregation and have tasks be moved to their non-preferred LLC.

Ack! I have replied to Chenyu's response with an example of
"migrate_load" case that, as per my understanding, would be restricted
by this condition. If I'm missing something, please do let me know.
Otherwise, the intention looks good to me.

> 
> Will take a closer look to see if nr_balance_failed > 0
> because we cannot move tasks to their preferred LLC repeatedly, and if
> we should do anything different to balance tasks better without violating
> LLC preference.

Thank you!

-- 
Thanks and Regards,
Prateek