linux-kernel - Re: [PATCH 0/3] Optimize code generation during context

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: <c6f8871a-5118-4947-9801-43b2a7a42993@redhat.com>
Date: Wed, 29 Oct 2025 11:26:39 +0100
From: David Hildenbrand <david@...hat.com>
To: Xie Yuanbin <qq570070308@...il.com>, riel@...riel.com,
 linux@...linux.org.uk, mathieu.desnoyers@...icios.com, paulmck@...nel.org,
 pjw@...nel.org, palmer@...belt.com, aou@...s.berkeley.edu, alex@...ti.fr,
 hca@...ux.ibm.com, gor@...ux.ibm.com, agordeev@...ux.ibm.com,
 borntraeger@...ux.ibm.com, svens@...ux.ibm.com, davem@...emloft.net,
 andreas@...sler.com, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
 dave.hansen@...ux.intel.com, hpa@...or.com, luto@...nel.org,
 peterz@...radead.org, acme@...nel.org, namhyung@...nel.org,
 mark.rutland@....com, alexander.shishkin@...ux.intel.com, jolsa@...nel.org,
 irogers@...gle.com, adrian.hunter@...el.com, anna-maria@...utronix.de,
 frederic@...nel.org, juri.lelli@...hat.com, vincent.guittot@...aro.org,
 dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
 mgorman@...e.de, vschneid@...hat.com, thuth@...hat.com,
 akpm@...ux-foundation.org, lorenzo.stoakes@...cle.com,
 segher@...nel.crashing.org, ryan.roberts@....com, max.kellermann@...os.com,
 urezki@...il.com, nysal@...ux.ibm.com
Cc: x86@...nel.org, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
 linux-s390@...r.kernel.org, sparclinux@...r.kernel.org,
 linux-perf-users@...r.kernel.org, will@...nel.org
Subject: Re: [PATCH 0/3] Optimize code generation during context

On 25.10.25 19:37, Xie Yuanbin wrote:
> On Fri, 24 Oct 2025 17:36:06 -0400, Rik van Riel wrote:
>> Also, what kind of performance improvement
>> have you measured with these changes?
> 
> When I debugged performance issues before, I used the company's equipment.
> I could only observe the macro business performance data, but not the
> specific scheduling time. Today I did some testing using my devices,
> and the testing logic is as follows:
> ```
> -	return finish_task_switch(prev);
> +	start_time = rdtsc();
> +	barrier();
> +	rq = finish_task_switch(prev);
> +	barrier();
> +	end_time = rdtsc;
> +	return rq;
> ```
> 
> The test data is as follows:
> 1. mitigations Off, without patches: 13.5 - 13.7
> 2. mitigations Off, with patches: 13.5 - 13.7
> 3. mitigations On, without patches: 23.3 - 23.6
> 4. mitigations On, with patches: 16.6 - 16.8

Such numbers absolutely have to be part of the relevant patches / cover 
letter to show that the compiler is not actually smart enough to make a 
good decision.

Having that said, sometimes it helps to understand "why" the compiler 
does a bad job, and try to tackle that instead.

For example, compilers will not inline functions that might be too big 
(there is a compiler tunable), factoring out slow-paths etc could help 
to convince the compiler to do the right thing.

Of course, it's not always possible, and sometimes we just now that we 
always want to inline.

-- 
Cheers

David / dhildenb