linux-kernel - Re: IPC drop down on AMD epyc 7702P

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: <db7b5ad7-3dad-4e7c-a323-d0128ae818eb@ateme.com>
Date: Fri, 16 May 2025 15:05:55 +0000
From: Jean-Baptiste Roquefere <jb.roquefere@...me.com>
To: K Prateek Nayak <kprateek.nayak@....com>, Vincent Guittot
	<vincent.guittot@...aro.org>
CC: Peter Zijlstra <peterz@...radead.org>, "mingo@...nel.org"
	<mingo@...nel.org>, Juri Lelli <juri.lelli@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Borislav
 Petkov <bp@...en8.de>, Dietmar Eggemann <dietmar.eggemann@....com>, Steven
 Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>, Mel Gorman
	<mgorman@...e.de>, "Gautham R. Shenoy" <gautham.shenoy@....com>, Swapnil
 Sapkal <swapnil.sapkal@....com>, Valentin Schneider <vschneid@...hat.com>,
	"regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: IPC drop down on AMD epyc 7702P

Hello Prateek,
long time no see... I've been very busy lately.

Did he try with relax_domain_level=3, i.e. prevent newilde idle


>> balance between LLC ? I don't see results showing that it's not enough
>> to prevent newly idle migration between LLC
>
> I don't think he did. JB if it isn't too much trouble, could you please
> try running with "relax_domain_level=3" in kernel cmdline and see if
> the performance is similar to "relax_domain_level=2".

I just tried relax_domain_level=3 on my payload. As you can see 
relax_domain_level=3 performances are more or less the same

+--------------------+---------------------+---------------------+
| Kernel             | 6.12.17 relax dom 2 | 6.12.17 relax dom 3 |
+--------------------+---------------------+---------------------+
| Utilization (%)    | 52,01               | 52,15 |
| CPU effective freq | 1 294,12            | 1 309,85 |
| IPC                | 1,42                | 1,40 |
| L2 access (pti)    | 38,18               | 38,03 |
| L2 miss   (pti)    | 7,78                | 7,90 |
| L3 miss   (abs)    | 33 929 609 924,00   | 33 705 899 797,00 |
| Mem (GB/s)         | 49,10               | 48,91 |
| Context switches   | 107 896 729,00      | 106 441 463,00 |
| CPU migrations     | 16 075 947,00       | 18 129 700,00 |
| Real time (s)      | 193,39              | 193,41 |
+--------------------+---------------------+---------------------+

We got the point that tuning this variable is not a good solution, but 
for now it's the only one we can apply.

Without this tuning our solution loses real time video processing. With 
: we keep real time on.


Thanks for your help, I'll stay alert on this thread if someday a better 
solution can emerge.


Regards,


jb