linux-kernel - Re: [PATCH v2 04/23] sched/cache: Make LLC id continuous

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] [day] [month] [year] [list]

Message-ID: <cdf373ca-8c72-45a5-b307-541acbfa82ed@amd.com>
Date: Fri, 26 Dec 2025 08:47:05 +0530
From: K Prateek Nayak <kprateek.nayak@....com>
To: "Chen, Yu C" <yu.c.chen@...el.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>, 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>, "Vern Hao"
	<haoxing990@...il.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>, Ingo Molnar <mingo@...hat.com>, Adam Li
	<adamli@...amperecomputing.com>, Aaron Lu <ziqianlu@...edance.com>, Tim Chen
	<tim.c.chen@...el.com>, <linux-kernel@...r.kernel.org>, Vincent Guittot
	<vincent.guittot@...aro.org>, Peter Zijlstra <peterz@...radead.org>, "Gautham
 R . Shenoy" <gautham.shenoy@....com>, Tim Chen <tim.c.chen@...ux.intel.com>
Subject: Re: [PATCH v2 04/23] sched/cache: Make LLC id continuous

Hello Chenyu,

On 12/24/2025 3:16 PM, Chen, Yu C wrote:
>> Only case I can think of is a task wakes up after partitioning
>> and it's wake cpu from a different partition is mistaken to
>> share the LLC as the current CPU - but the task cannot actually
>> run on that old CPU and it'll have to take the
>> select_fallback_rq() path if prev_cpu was selected during
>> wake_affine().
>>
> 
> OK, make sense.
> Actually, prev_cpu might not be chosen by select_task_rq_fair()->
> select_idle_sibling(), because fast path select_idle_sibling()
>  is expected to be triggered when prev_cpu and the current cpu are in the
> same domain in select_task_rq_fair():
> cpumask_test_cpu(prev_cpu, sched_domain_span(tmp))
>     sd = NULL; //wake affine

Then again, there are cases where want_affine is false, and
"new_cpu" is initialized to the prev_cpu and we continue down
to select_idle_sibling() since "tmp->flags & sd_flag" is
always false - WF_TTWU matches with SD_BALANCE_WAKE but no
domain sets it anymore afaict.

Again, going through the fallback selection path should be
rare (once after partition on wakeup) and shouldn't cause any
problems for most real-world scenarios.

> curr cpu and prev_cpu are in different partitions, they
> are not in the same domains.
> 
>> I don't think it will be such a common occurence to cause an
>> issue and even without that wake_affine() could still the
>> prev_cpu if current CPU is busy or via wake_affine_weight().
>>
> 
> I realized that sched_cache has added cpus_share_cache() in
> several places, most of which should be related to load
> balancing, which should not be a problem if llc_id is shared
> among partitions. I'll double check.

Thank you!

-- 
Happy Holidays!
Thanks and Regards,
Prateek